чем другая?

Тем, что я не сохраняю никуда и потом не читаю

сдрастье

->> это сохранение в память, а ::numeric это чтение из памяти

там теже функции вызываются что при pg_dump

->> это сохранение в память, а ::numeric это чтение из памяти

Вообще говоря это преобразование из text в numeric

только вместо файла — строка в памяти

ага

Вообще говоря это преобразование из text в numeric

из jsonb в text, из text в numeric

из jsonb в text, из text в numeric

Нет, не jsonb, а json

осталось доказать что оба преобразования не теряют данные

Я понял, что с jsonb могут быть проблемы, так как он хранит как числа

для json должно быть норм, там же нет двойного преобразования, просто однократный numeric из текста

для json должно быть норм, там же нет двойного преобразования, просто однократный numeric из текста

Супер! Что я и добивался

как минимум json::text::numeric::text != json::text

угу

Окей, не спорю здесь

в pg11 есть прямые касты из jsonb в числа, с ними приятнее

а как их использовать?

а как их использовать?

('{"a":5.678e-05}'::jsonb->'a')::numeric;

одна, а не две, стрелочки

а, ясно

Я понял, что с jsonb могут быть проблемы, так как он хранит как числа

(Я всё пропустил.) А какие проблемы-то?

Проблемы могут быть в преобразовании jsonb->text->numeric.

Если я правильно понял, то мы все сошлись, что json->text->numeric норм.

Проблемы могут быть в преобразовании jsonb->text->numeric.

jsonb какого JSON-типа, number? И какие?

Соответсвенно два примера: select ('{"a":1e-379}'::json->>'a')::numeric; select ('{"a":1e-379}'::jsonb->>'a')::numeric;

jsonb какого JSON-типа, number? И какие?

Ага

Соответсвенно два примера: select ('{"a":1e-379}'::json->>'a')::numeric; select ('{"a":1e-379}'::jsonb->>'a')::numeric;

Хмм... одинаковые результаты, на первый взгляд. Я чего-то не вижу?

Эмм... я сказал, что "могут быть". Примера я такого не знаю.

Эмм... я сказал, что "могут быть". Примера я такого не знаю.

Так откуда это вообще взялось, что они "могут быть", в таком случае?

Вот была такая фраза. Я зацепился за неё.

вот и я про json. оно неявно конвертировало числа сначала в текст, а потом в число. что чревато проблемами как раз с плавающей точкой

преобразует "1e2" из текста в бинарное число. потом достанет его и преобразует в текст из бинарного. потом из текстового будет опять преобразовывать в numeric. а чтобы напечатать на экране будет преобразовывать его обратно в текст

Наш холивар как всегда образ тоннами сообщений, поэтому далее можно читать вот отюда.

вот и я про json. оно неявно конвертировало числа сначала в текст, а потом в число. что чревато проблемами как раз с плавающей точкой

Так JSON или JSONB? Разные же вещи.

вот и я про json. оно неявно конвертировало числа сначала в текст, а потом в число. что чревато проблемами как раз с плавающей точкой

Вот тут про JSON. Не jsonb

Вот тут про JSON. Не jsonb

И всё равно я не понимаю, о каком случае речь. :( И, далее, причём тут вообще JSONB. ;)

jsonb мы здесь просто так затронули

Вообщем я понял, что тот Алексей Копытов сначала сказал о какой-то страшной проблеме. А потом всё свёл к тому, что есть доп. преобразования, которые замедляют работу. Хотя изначально посыл был такой, что там есть проблемы с плавающей точкой.

Вообщем я понял, что тот Алексей Копытов сначала сказал о какой-то страшной проблеме. А потом всё свёл к тому, что есть доп. преобразования, которые замедляют работу. Хотя изначально посыл был такой, что там есть проблемы с плавающей точкой.

А где он это сказал? Может, можно его спросить, что он имел в виду?

Чатик ru_mysql.

Чатик ru_mysql.

Да, вижу, спасибо!

c json в куче мест есть проблема с тем, что число там в большинстве имплементаций - double

Ну а PostgreSQL-то тут причём? ;)

ну вот драйвер постгреса в ноде такой

а PostgreSQL тут при том, что умеет конвертировать float8 -> text, float8 -> numeric и обратно только с потерями. подробности здесь: https://www.postgresql.org/message-id/flat/5A937D7E.60305%40anastigmatix.net

а PostgreSQL тут при том, что умеет конвертировать float8 -> text, float8 -> numeric и обратно только с потерями. подробности здесь: https://www.postgresql.org/message-id/flat/5A937D7E.60305%40anastigmatix.net

только в парсинге json не используется float8 в постгресе

речь про jsonb естественно

конечно там разговор был вовсе не об этом

ну вот драйвер постгреса в ноде такой

Проблемы "ноды", нет? ;) Вообще, если какой-то "клиентский" язык / API не умеет преобразовывать типы из базы в свои 1:1 (не имеет таких типов), но всё равно делает это (а не пользуется текстовым/бинарным представлением) — это они совсем зря. :(

речь про jsonb естественно

и в jsonb тоже, там numeric внутри

Проблемы "ноды", нет? ;) Вообще, если какой-то "клиентский" язык / API не умеет преобразовывать типы из базы в свои 1:1 (не имеет таких типов), но всё равно делает это (а не пользуется текстовым/бинарным представлением) — это они совсем зря. :(

ну вообще говоря json родом из javascript, так что то, что его иногда имплементируют не так, как в ноде, ещё вопрос чья проблема :)

речь про jsonb естественно

Да, там используется numeric. Причём тут вообще float?

ну вообще говоря json родом из javascript, так что то, что его иногда имплементируют не так, как в ноде, ещё вопрос чья проблема :)

Ну а PostgreSQL реализует https://tools.ietf.org/html/rfc7159 , так что, к счастью, от плохой наследственности мы избавлены. ;)

и вот прямо по этой ссылочке написано: "This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision."

так что, numeric хоть и не противоречит стандарту, но влечёт "interoperability problems"

хотя да, снимаю свои комментарии про точность. проблема с производительностью остаётся актуальной до pg11

так что, numeric хоть и не противоречит стандарту, но влечёт "interoperability problems"

Эти проблемы (почти) всегда есть. Типы в базах зачастую вообще "круче", чем в языках программирования общего назначения. Просто во многих приложениях на это широко закрывают глаза. ;)

Эти проблемы (почти) всегда есть. Типы в базах зачастую вообще "круче", чем в языках программирования общего назначения. Просто во многих приложениях на это широко закрывают глаза. ;)

а сколько языков программирования, где есть numeric?

а сколько языков программирования, где есть numeric?

Понятия не имею, естественно. ;) Но вот нет numeric-а очень много где.

о том и речь

Да, я перечитал. Там действительно разговор был про jsonb. Просто иногда в примеры писались с json, что меня смутило.

о том и речь

Ну так СУБД зачастую разрабатывают те, кому нравятся более мощные типы... (И, по идее, они даже умеют с ними работать.) ;)

<и тут должен быть холивар на тему "мощности" numeric и определения "мощности" типов данных вообще, но лень>

Неужели Вы из этого смогли бы устроить holywar? ;)

<и здесь должен быть холивар про холивар, но лень>

https://www.bestchange.ru/?p=817980

#spam

@shahzodshafizod будет жить. Поприветствуем!

интересный бот

Извиняюсь если оффтоп немного. Есть MySQL InnoDB таблица с 23 миллионами записей и 16 гигами на винчестере. У неё десяток с лишним полей имеют тип longtext, и на них full-text индексы. Если делать поиск только по одному из этих полей, работает ок. Если я полнотекстовый поиск комбинирую, например с WHERE ID > 20000, в лучшем случае 2 минуты запрос занимает, в худшем, вылетает с ошибкой, что не хватает памяти. Тут можно что-нибудь сделать, или надо переходить на NoSQL?

Вот тут более подробно https://dba.stackexchange.com/questions/216978/mysql-innodb-full-text-search-is-very-slow-when-combined-with-other-filters

Mike будет жить. Поприветствуем!

Извиняюсь если оффтоп немного. Есть MySQL InnoDB таблица с 23 миллионами записей и 16 гигами на винчестере. У неё десяток с лишним полей имеют тип longtext, и на них full-text индексы. Если делать поиск только по одному из этих полей, работает ок. Если я полнотекстовый поиск комбинирую, например с WHERE ID > 20000, в лучшем случае 2 минуты запрос занимает, в худшем, вылетает с ошибкой, что не хватает памяти. Тут можно что-нибудь сделать, или надо переходить на NoSQL?

Тут и NoSQL особо не поможет.

А в какую сторону копать тогда?

Извиняюсь если оффтоп немного. Есть MySQL InnoDB таблица с 23 миллионами записей и 16 гигами на винчестере. У неё десяток с лишним полей имеют тип longtext, и на них full-text индексы. Если делать поиск только по одному из этих полей, работает ок. Если я полнотекстовый поиск комбинирую, например с WHERE ID > 20000, в лучшем случае 2 минуты запрос занимает, в худшем, вылетает с ошибкой, что не хватает памяти. Тут можно что-нибудь сделать, или надо переходить на NoSQL?

Суть в том, что если ты ищешь по одному индексу, то у тебя (если всё ок) тупо работает поиск по индексу, который при хорошем стечении обстоятельств (большой селективности критерия отбора) даст тебе мало записей, и соотв. всё ок. А если ты используешь два индекса, то во-первых, селективность критерия отбора разбивается на две части, и поскольку селективность совокупности критериев это произведение отдельных селективностей, а селективность части из совокупности критериев, наоборот, частное, то селективность в этом случае очень резко падает , т.е. критерий поиска по одному индексу даёт тебе резко (на порядки) больше записей. во-вторых, поскольку используется несколько индексов, то даже если СУБД умеет использовать несколько индексов в запросе, то она должна сделать сначала поиск по одному, затем по другому, потом сделать пересечение двух множеств, производительность этой операции не самая лучшая в мире. Т.е. это всё будет медленно во всех случаях. NoSQL тут ничего не решает, там всё то же самое, только без SQL.

Понятно, спасибо. И это вообще никак не лечится? Там не знаю, SSD поставить, хадуп-кластер какой-нибудь.

Понятно, что наверно по железу вложиться придётся, раз база такая здоровая в плане текста.

Суть в том, что если ты ищешь по одному индексу, то у тебя (если всё ок) тупо работает поиск по индексу, который при хорошем стечении обстоятельств (большой селективности критерия отбора) даст тебе мало записей, и соотв. всё ок. А если ты используешь два индекса, то во-первых, селективность критерия отбора разбивается на две части, и поскольку селективность совокупности критериев это произведение отдельных селективностей, а селективность части из совокупности критериев, наоборот, частное, то селективность в этом случае очень резко падает , т.е. критерий поиска по одному индексу даёт тебе резко (на порядки) больше записей. во-вторых, поскольку используется несколько индексов, то даже если СУБД умеет использовать несколько индексов в запросе, то она должна сделать сначала поиск по одному, затем по другому, потом сделать пересечение двух множеств, производительность этой операции не самая лучшая в мире. Т.е. это всё будет медленно во всех случаях. NoSQL тут ничего не решает, там всё то же самое, только без SQL.

А если СУБД не умеет более одного индекса на таблицу использовать (это 80% всех СУБД), то у тебя будет браться один индекс, и одна из двух селективностей по нему, плохая, в соотв. с пунктом (1) вышеизложенного. Тоже хреново.

Понятно, спасибо. И это вообще никак не лечится? Там не знаю, SSD поставить, хадуп-кластер какой-нибудь.

Лечится мозгом.

Всмысле не делать базы подобной структуры?)

Понятно, спасибо. И это вообще никак не лечится? Там не знаю, SSD поставить, хадуп-кластер какой-нибудь.

Обычно денормализуют данные, сваливают всё в одно поле, но так, чтобы можно было искать, естественно, и делают индек на неё. Если о РБД говорить, то это был бы индекс на фукнцию использующий поля из двух таблиц. А тут надо слить это в одно поле, но так, чтобы ты знал, где данные из какого, естественно. Например, если это xml, то сделать два-три подкорневых элемента с именами подполей, отражающих имена исходных полей, и задействовать эти имена в поиске.

Всмысле не делать базы подобной структуры?)

Нет, не это конечно

Понял, спасибо огромное.

Всем привет! А кто разбирается в блокировках таблиц у постгреса? Запускаю два процесса по очереди, в обоих стоит блокировка таблицы, в первом слип на 60 секунд, во втором - уже нет. Второй ждет секунд 30 и выполняется полностью, вносит запись в заблокированную таблицу, пока первый процесс спит, в итоге первичный ключ перескакивает одно значение. вторая транзакция ждет первую, но не может дождаться Как это решать?

Обычно денормализуют данные, сваливают всё в одно поле, но так, чтобы можно было искать, естественно, и делают индек на неё. Если о РБД говорить, то это был бы индекс на фукнцию использующий поля из двух таблиц. А тут надо слить это в одно поле, но так, чтобы ты знал, где данные из какого, естественно. Например, если это xml, то сделать два-три подкорневых элемента с именами подполей, отражающих имена исходных полей, и задействовать эти имена в поиске.

Последний глупый вопрос: я все поисковые поля солью в одну колонку, повешу индекс на неё, структурирую, допустим. А есть вторая колонка числовая Area. Получается, что отбор на две части разобьётся, и что в лоб, что по лбу будет.

ребят. Подскажите, как данный запрос можно оптимизировать для большого колличества записей

SELECT intAutoID AS intLastMessageID FROM ( SELECT intAutoID, COUNT(1), MAX(datSentDate) , intSenderID, intReceiverID, CONCAT(LEAST(intSenderID, intReceiverID), ":", GREATEST(intSenderID, intReceiverID) ) AS roomkey FROM tblmessages WHERE intSenderID != intReceiverID GROUP BY roomkey ORDER BY intSenderID) AS custom;

Понял, спасибо огромное.

Ну, кстати по полнотестовым индексам может быть всё с этим делом ещё хуже. Я как бы в уме НЕ держал, что полнотекстовый от простого отличается, когда отвечал. Там может очень сильно ещё зависить от того, какой критерий поиска в итоге получится, и сможет ли он оптимизироваться. Покажи применый запрос.

Всем привет! А кто разбирается в блокировках таблиц у постгреса? Запускаю два процесса по очереди, в обоих стоит блокировка таблицы, в первом слип на 60 секунд, во втором - уже нет. Второй ждет секунд 30 и выполняется полностью, вносит запись в заблокированную таблицу, пока первый процесс спит, в итоге первичный ключ перескакивает одно значение. вторая транзакция ждет первую, но не может дождаться Как это решать?

Что PK перескакивает значения -- это воообще не проблема, и никак не связано с блокировками. Если ты конечно новые ID не сам генерируешь через (select max(id) ...)

Ну, кстати по полнотестовым индексам может быть всё с этим делом ещё хуже. Я как бы в уме НЕ держал, что полнотекстовый от простого отличается, когда отвечал. Там может очень сильно ещё зависить от того, какой критерий поиска в итоге получится, и сможет ли он оптимизироваться. Покажи применый запрос.

SELECT * FROM robjects WHERE MATCH(type) AGAINST ('commercial' IN BOOLEAN MODE) LIMIT 10 Вот так быстро работает SELECT * FROM robjects WHERE MATCH(type) AGAINST ('commercial' IN BOOLEAN MODE) AND ID > 20000 LIMIT 10 Вот так уже на две минуты в зависон уходит. Если ещё один MATCH AGAINST добавить, то вообще трындец.

ребят. Подскажите, как данный запрос можно оптимизировать для большого колличества записей

напиши лучше что надо получить

нужно получить уникальные записи по senderID и receiverID. Одну запись по intAutoID(уникальную). Запрос правильно работает. Но для больших данных очень долго

Последний глупый вопрос: я все поисковые поля солью в одну колонку, повешу индекс на неё, структурирую, допустим. А есть вторая колонка числовая Area. Получается, что отбор на две части разобьётся, и что в лоб, что по лбу будет.

Зависит от селективности критерия отбора. Если селективность по полнотекстовому будет большая, а иначе и делать это всё бесссмысленно, то что там будет во вторичных фильтрах -- да по барабану. Ну выйдет у тебя из индекса не 10 строк, а 30, и 2/3 потом уберётся за счёт доп-условий. Ну, всё равно производительность хорошая будет.

ребят. Подскажите, как данный запрос можно оптимизировать для большого колличества записей

Для начала GROUB BY нормально напиши. SELECT intAutoID, COUNT(1), MAX(datSentDate) , intSenderID, intReceiverID, CONCAT(LEAST(intSenderID, intReceiverID), ":", GREATEST(intSenderID, intReceiverID) ) AS roomkey FROM tblmessages WHERE intSenderID != intReceiverID GROUP BY roomkey ORDER BY intSenderID

Для начала GROUB BY нормально напиши. SELECT intAutoID, COUNT(1), MAX(datSentDate) , intSenderID, intReceiverID, CONCAT(LEAST(intSenderID, intReceiverID), ":", GREATEST(intSenderID, intReceiverID) ) AS roomkey FROM tblmessages WHERE intSenderID != intReceiverID GROUP BY roomkey ORDER BY intSenderID

Парни, а что , такую лабуду PG даёт запускать? Я что-то уже не помню, но мне казалось, что в PG с этим строго.