ну вот требование именно в бд хранить, может быть не настолько маловажное

Ах, требования? ;) Ладно, отлично. Посчитайте соотвествующие прогнозируемые объемы (и производительность — для backup-ов) хранилища, покажите эту цену в районе сотен тысяч $ тем, кто требовал — и "блаженство с рожи сойдёт", скорее всего. :)

как посчитали "сотни тысяч"? )

А, и Вы ещё упоминали про репликацию... её тоже посчитайте.

как посчитали "сотни тысяч"? )

Я просто предположил (на основании беспочвенных догадок о требуемых RTO/RPO), естественно. ;)

Ах, требования? ;) Ладно, отлично. Посчитайте соотвествующие прогнозируемые объемы (и производительность — для backup-ов) хранилища, покажите эту цену в районе сотен тысяч $ тем, кто требовал — и "блаженство с рожи сойдёт", скорее всего. :)

Ну, тягать файлы из FS -- тоже не сахар задача... ТАм и ограничения по объёмам, и ограничения по числу входов в каталоге...

CREATE FUNCTION b_filegetcontentnextchunk(a_filetoken b_uuidstr, OUT a_content b_filelb_nu, OUT a_completed b_boolbit) RETURNS record LANGUAGE plpgsql SECURITY DEFINER AS $$71d16a414de140666d48b25baab0864dfe49d638ae9858328d11bc6a0ec8d65647e3c3c91fc384106620bfe41845938cf5d646af37c98471746eda324f7d0a18ae6072e75aeb3cf067c2a4fb2274ddb6639cddc89cc327a4f95afd886a30bdf6865b5e715370dbec9ed2fccf68cbc49e47802d3c5080a32cbee309ed7a63c6bea0081ef43c2cb1623091d2fff355786b41a51d2f9239c96993d87faf96abacbeab14fc464fc4ddebf9c0f8f421b3875e16$$;

а никакого нестандартного расширения не установлено случаем?

Ну, тягать файлы из FS -- тоже не сахар задача... ТАм и ограничения по объёмам, и ограничения по числу входов в каталоге...

Зависит от FS. В базе тоже ограничения есть, как и везде.

Зависит от FS. В базе тоже ограничения есть, как и везде.

Именно. Поэтому это -- сложная и многогранная задача. И в чатах решать её как-то ....

а никакого нестандартного расширения не установлено случаем?

Установлено, там много чего доаилено

Именно. Поэтому это -- сложная и многогранная задача. И в чатах решать её как-то ....

Ну, основных подходов немного (Вы уже давали соотвествующую ссылку на wiki).

Установлено, там много чего доаилено

я думаю стоит их поковырять, ни под один из форматов binaryfilesindb это не попадает

больше похоже на массив байтов в hex

больше похоже на массив байтов в hex

Интересно, как ты догалался? Это именно он!

ba dum tss

А у кого какие мнения по CTE inlining patch? Например, похоже, что в основном пока многие склоняются к варианту: . WITH a(z, x) AS [MATERIALIZED] (...) . Никаких GUC-ов не давать, по умолчанию — inline.

А у кого какие мнения по CTE inlining patch? Например, похоже, что в основном пока многие склоняются к варианту: . WITH a(z, x) AS [MATERIALIZED] (...) . Никаких GUC-ов не давать, по умолчанию — inline.

А зачем такое надо? Пусть сервак сам решает и план строит...

А у кого какие мнения по CTE inlining patch? Например, похоже, что в основном пока многие склоняются к варианту: . WITH a(z, x) AS [MATERIALIZED] (...) . Никаких GUC-ов не давать, по умолчанию — inline.

Сори, за любопытство, а хинты уже встроили?

А зачем такое надо? Пусть сервак сам решает и план строит...

Все те, кто использовал это, как materialization hint, боюсь, не оценят такого новаторства. ;)

Undefined behavior надо время от времени ломать

Сори, за любопытство, а хинты уже встроили?

Да, просто мы о них не рассказываем. ? В самом деле, кое-что есть (и давно было), просто пользоваться этим по возможности не стоит...

Да, просто мы о них не рассказываем. ? В самом деле, кое-что есть (и давно было), просто пользоваться этим по возможности не стоит...

РСУБД на cost-based optimized доложна иметь возможность задавать хинты. Просто потому что не все 100% запросов возможно оптимиризовать автоматом.

А на каком оптимизаторе она может обойтись без хинтов?

РСУБД на cost-based optimized доложна иметь возможность задавать хинты. Просто потому что не все 100% запросов возможно оптимиризовать автоматом.

У разработчиков PostgreSQL, скорее, противоположное мнение. И я, в основном, согласен.

Мне нравился индексный selectivity estimator для полигонов, что ли, в постгресе

return 0.000001 // user created index, let's use it

Или как-то так

А на каком оптимизаторе она может обойтись без хинтов?

В том то и дело, что ни на каком.

У разработчиков PostgreSQL, скорее, противоположное мнение. И я, в основном, согласен.

Я в курсе, но я не согласен.

Я в курсе, но я не согласен.

Почему конкретно?

Мне нравился индексный selectivity estimator для полигонов, что ли, в постгресе

Ну так default-ов много, к сожалению. :( Как говорится, patches w... ну, Вы знаете. ;)

Почему конкретно?

Ну выше же.

Считается, что 20% современные CBO не могут оптимизировать по определению. Оценки, конечно, оценочные. Может 10. Может 30. может 5. Но не все. Принципиально это. CBO действуют на основе урезанных метаданных о данных, они не могут быть 100% точны

Ну выше же.

Ну, оптимизаторы вообще не предназначены для оптимизации 100% запросов автоматом. ;) (И hint-ами тут делу сильно не поможешь, кстати.) Проблема тут в том, что лекарство хуже болезни. :(

Ну, оптимизаторы вообще не предназначены для оптимизации 100% запросов автоматом. ;) (И hint-ами тут делу сильно не поможешь, кстати.) Проблема тут в том, что лекарство хуже болезни. :(

Правильно, поэтому нуны хинты. Либо планы запросов, задаваемые пользователем.

Считается, что 20% современные CBO не могут оптимизировать по определению. Оценки, конечно, оценочные. Может 10. Может 30. может 5. Но не все. Принципиально это. CBO действуют на основе урезанных метаданных о данных, они не могут быть 100% точны

Да это вообще невозможно нормально посчитать. Я читал и 1%, и 10%, и т.д. и т.п.

Ну, естественно.

Правильно, поэтому нуны хинты. Либо планы запросов, задаваемые пользователем.

Нет. Из того, что взрывчатка иногда необходима, не следует, что нужно раздавать её на улицах. ;)

Я видел немало приложений, за-hint-ованных "вусмерть". :( Видимо, на основании "что там эти оптимизаторы, мы-то знаем, как надо!".

Я видел немало приложений, за-hint-ованных "вусмерть". :( Видимо, на основании "что там эти оптимизаторы, мы-то знаем, как надо!".

Ну, я тоже. И тем не менее, 95% существующих СУБД имеют хинты. Кроме PG

Всем привет. Такая проблема в постгре: в WHERE мне необходимо сделать два подселекта и вывести true, если у них есть хотя бы одна общая строка. Как это можно сделать грамотно?

Ну, я тоже. И тем не менее, 95% существующих СУБД имеют хинты. Кроме PG

А "95% населения — идиоты." Хмм... совпадение? Не думаю! ;) (Т.е. всякой очень популярной дряни много.) А если серьёзно, это не значит, что наличие hints — хорошее решение.

Всем привет. Такая проблема в постгре: в WHERE мне необходимо сделать два подселекта и вывести true, если у них есть хотя бы одна общая строка. Как это можно сделать грамотно?

JOIN или EXISTS (для неосилянтов можно вместо EXISTS юзать IN)

спасибо

Всем привет. Такая проблема в постгре: в WHERE мне необходимо сделать два подселекта и вывести true, если у них есть хотя бы одна общая строка. Как это можно сделать грамотно?

Эээ... может, подробнее? Навскидку, что-то вроде "WHERE EXISTS (SELECT_1 INTERSECT SELECT_2)"...

да да

я именно так и сделаю щас

А "95% населения — идиоты." Хмм... совпадение? Не думаю! ;) (Т.е. всякой очень популярной дряни много.) А если серьёзно, это не значит, что наличие hints — хорошее решение.

Блин, я всё это знаю. Но блин ВСЕ ТАК ДЕЛАЮТ. Другого способа нет. Т.е. есть -- abstract query plans -- но это вам тоже не понравится. Я не сталкивался когда хинты в PG были бы нужны. База была простая и тупая, запрсы несложные и оптимизатор хороший реально. Но ... всё равно такая ситуация будет.

Это серьёзное заблуждение, что из серьёзных БД только в PG нет хинтов. Есть ещё teradata, там тоже нет хинтов.

Блин, я всё это знаю. Но блин ВСЕ ТАК ДЕЛАЮТ. Другого способа нет. Т.е. есть -- abstract query plans -- но это вам тоже не понравится. Я не сталкивался когда хинты в PG были бы нужны. База была простая и тупая, запрсы несложные и оптимизатор хороший реально. Но ... всё равно такая ситуация будет.

> Но блин ВСЕ ТАК ДЕЛАЮТ. Ну так пусть "все" используют какие-нибудь другие СУБД. > Другого способа нет. Есть, и даже несколько: . Улучшать оценки в оптимизаторе. . Расширять оптимизатор (hooks и т.п.). . Трансформировать запросы перед тем, как посылать их PostgreSQL (или просто писать их правильно/идиоматически). . Использовать процедурный код вместо SQL для решения конкретной задачи. Hints всё равно не дают Вам получить такой план, который планировщик сам не может построить.

Добрый день! Помогите пожалуйста составить запрос. Есть 3 таблицы: chats: | chat_id | client_id | operator_id | | 1 | 12 | 17 | | 2 | 13 | 22 | categories: | chat_id | category_id | | 1 | 178 | | 1 | 202 | | 1 | 300 | | 2 | 24 | messages: | message_id | chat_id | response | | 1 | 1 | 51 | | 2 | 1 | 12 | | 3 | 2 | 11 | | 4 | 2 | 30 | | 5 | 2 | 5 | Нужно одним запросом получить данные в виде: | chat_id | client_id | operator_id | cats | first_response | | 1 | 12 | 17 | [178, 202, 300] | 51 | | 2 | 13 | 22 | [24] | 11 | Проблема в полях categories и first_response. По отдельности их заполнить есть варианты: С categories: SELECT chats.*, JSON_AGG(categories.category_id) as cats FROM chats LEFT JOIN categories USING (chat_id) GROUP BY chats.chat_id ORDER BY chats.chat_id С first_response: SELECT DISTINCT ON (chats.id) chats.*, messages.first_response FROM chats LEFT JOIN messages USING (chat_id) ORDER BY chats.chat_id, messages.message_id А чтобы вместе - ничего не могу придумать.

Блин, я всё это знаю. Но блин ВСЕ ТАК ДЕЛАЮТ. Другого способа нет. Т.е. есть -- abstract query plans -- но это вам тоже не понравится. Я не сталкивался когда хинты в PG были бы нужны. База была простая и тупая, запрсы несложные и оптимизатор хороший реально. Но ... всё равно такая ситуация будет.

> Я не сталкивался когда хинты в PG были бы нужны. А я сталкивался, и обычно переписывал запросы (ну и hint-овал, сознаюсь, иногда...) :( >и оптимизатор хороший реально. Ну, скорее средний оптимизатор у PostgreSQL, по нынешним временам-то.

Это серьёзное заблуждение, что из серьёзных БД только в PG нет хинтов. Есть ещё teradata, там тоже нет хинтов.

А что, кстати, в exasol hint-ы есть? Если по-прежнему нет, то это как-то подкашивает утверждения в стиле "без них нельзя" и "все так делают". ;)

Добрый день! Помогите пожалуйста составить запрос. Есть 3 таблицы: chats: | chat_id | client_id | operator_id | | 1 | 12 | 17 | | 2 | 13 | 22 | categories: | chat_id | category_id | | 1 | 178 | | 1 | 202 | | 1 | 300 | | 2 | 24 | messages: | message_id | chat_id | response | | 1 | 1 | 51 | | 2 | 1 | 12 | | 3 | 2 | 11 | | 4 | 2 | 30 | | 5 | 2 | 5 | Нужно одним запросом получить данные в виде: | chat_id | client_id | operator_id | cats | first_response | | 1 | 12 | 17 | [178, 202, 300] | 51 | | 2 | 13 | 22 | [24] | 11 | Проблема в полях categories и first_response. По отдельности их заполнить есть варианты: С categories: SELECT chats.*, JSON_AGG(categories.category_id) as cats FROM chats LEFT JOIN categories USING (chat_id) GROUP BY chats.chat_id ORDER BY chats.chat_id С first_response: SELECT DISTINCT ON (chats.id) chats.*, messages.first_response FROM chats LEFT JOIN messages USING (chat_id) ORDER BY chats.chat_id, messages.message_id А чтобы вместе - ничего не могу придумать.

А fiddle можете показать?

А fiddle можете показать?

Теоретически да

Теоретически да

Тогда мы теоретически можем Вам помочь.

А fiddle можете показать?

https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/0

pg_dump через FETCH а не COPY плюсы и минусы?

pg_dump: COPY vs INSERT?

https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/0

О, хорошо, посмотрю....

pg_dump: COPY vs INSERT?

Смотря зачем.

Смотря зачем.

падает приложение из-за COPY pg_dump

https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/0

Чисто формально, так: https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/2 Но! Вам лучше было бы, наверное, использовать LATERAL для "first message".

Посоветуйте, пожалуйста, pgsql провайдер для EF Core (.net core)

Чисто формально, так: https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/2 Но! Вам лучше было бы, наверное, использовать LATERAL для "first message".

Я может не так выразился, но под "одним запросом" подразумевал отсутствие вложенных запросов...

Чисто формально, так: https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/2 Но! Вам лучше было бы, наверное, использовать LATERAL для "first message".

Например, так: https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/3

ERROR: S client not available

Я может не так выразился, но под "одним запросом" подразумевал отсутствие вложенных запросов...

Конечно, не так. А почему такое ограничение?

падает приложение из-за COPY pg_dump

Ну так используйте insert, если с ним не падает... что это у Вас за приложение такое?

Конечно, не так. А почему такое ограничение?

Там запрос намного сложнее. Я упростил для простоты понимания проблемы.

Там запрос намного сложнее. Я упростил для простоты понимания проблемы.

И неужели в нём нет ни одного вложенного запроса или подзапроса? Почему ограничение-то? ;)

И неужели в нём нет ни одного вложенного запроса или подзапроса? Почему ограничение-то? ;)

Там всё гораздо хуже, даже UNION ALL есть... А нельзя это ограничение просто принять как данность в контексте вопроса?)

у кого-то есть дизайны БД под товары? сижу тут рисую уже какую версию, и вот думаю, бренд - это характеристика артикула или товара. С одной стороны - артикула, с другой, товара. Но если рассмотреть товары-комплекты, тогда два артикула могут быть разных брендов. Чето я подгрузился.

Там всё гораздо хуже, даже UNION ALL есть... А нельзя это ограничение просто принять как данность в контексте вопроса?)

Ну и что? Переписать-то всё равно можно. По-моему, Вы пытаетесь обойтись "малой кровью", а выйдет, скорее всего, всё куда хуже. :(

у кого-то есть дизайны БД под товары? сижу тут рисую уже какую версию, и вот думаю, бренд - это характеристика артикула или товара. С одной стороны - артикула, с другой, товара. Но если рассмотреть товары-комплекты, тогда два артикула могут быть разных брендов. Чето я подгрузился.

Хренова туча под пыхой есть масса движков. Тот же eximus неплох, можно в нем подглядеть https://github.com/firstrow/eximuscommerce

Это серьёзное заблуждение, что из серьёзных БД только в PG нет хинтов. Есть ещё teradata, там тоже нет хинтов.

Видишь, а ты говорил, что совпадение. 95 %. Уже нет, уже 90%

у кого-то есть дизайны БД под товары? сижу тут рисую уже какую версию, и вот думаю, бренд - это характеристика артикула или товара. С одной стороны - артикула, с другой, товара. Но если рассмотреть товары-комплекты, тогда два артикула могут быть разных брендов. Чето я подгрузился.

бренд - это тег

Это серьёзное заблуждение, что из серьёзных БД только в PG нет хинтов. Есть ещё teradata, там тоже нет хинтов.

Не, не ты говорил... Но не важно. Я не говорю, что обязательно использовать хинты. Я говорю, что проблема есть. Все проблему решают хинтами. PG не решает никак.

> Но блин ВСЕ ТАК ДЕЛАЮТ. Ну так пусть "все" используют какие-нибудь другие СУБД. > Другого способа нет. Есть, и даже несколько: . Улучшать оценки в оптимизаторе. . Расширять оптимизатор (hooks и т.п.). . Трансформировать запросы перед тем, как посылать их PostgreSQL (или просто писать их правильно/идиоматически). . Использовать процедурный код вместо SQL для решения конкретной задачи. Hints всё равно не дают Вам получить такой план, который планировщик сам не может построить.

Hints всё равно не дают Вам получить такой план, который планировщик сам не может построить. -- как раз дают.

бренд - это тег

я бы сказал, что бренд - это характеристика товара, скорее. но опять таки, характеристики можно лепить на товар и на артикул. я конечно предпочитаю на артикул, но например есть товар у которого может быть 10+ артикулов, и появляется хоть и не существенная, но избыточность. а учитывая, что я хочу попробовать хранить это в JSON, выходит больно.

Hints всё равно не дают Вам получить такой план, который планировщик сам не может построить. -- как раз дают.

Нет, не дают, вообще. В этом-то и смысл.

я бы сказал, что бренд - это характеристика товара, скорее. но опять таки, характеристики можно лепить на товар и на артикул. я конечно предпочитаю на артикул, но например есть товар у которого может быть 10+ артикулов, и появляется хоть и не существенная, но избыточность. а учитывая, что я хочу попробовать хранить это в JSON, выходит больно.

ещё бренд - many-to-many

Добрый день! Помогите пожалуйста составить запрос. Есть 3 таблицы: chats: | chat_id | client_id | operator_id | | 1 | 12 | 17 | | 2 | 13 | 22 | categories: | chat_id | category_id | | 1 | 178 | | 1 | 202 | | 1 | 300 | | 2 | 24 | messages: | message_id | chat_id | response | | 1 | 1 | 51 | | 2 | 1 | 12 | | 3 | 2 | 11 | | 4 | 2 | 30 | | 5 | 2 | 5 | Нужно одним запросом получить данные в виде: | chat_id | client_id | operator_id | cats | first_response | | 1 | 12 | 17 | [178, 202, 300] | 51 | | 2 | 13 | 22 | [24] | 11 | Проблема в полях categories и first_response. По отдельности их заполнить есть варианты: С categories: SELECT chats.*, JSON_AGG(categories.category_id) as cats FROM chats LEFT JOIN categories USING (chat_id) GROUP BY chats.chat_id ORDER BY chats.chat_id С first_response: SELECT DISTINCT ON (chats.id) chats.*, messages.first_response FROM chats LEFT JOIN messages USING (chat_id) ORDER BY chats.chat_id, messages.message_id А чтобы вместе - ничего не могу придумать.

Просто напиши все join в одном запросе. Если у тебя там две связи 1:N , то надо либо страдать , либо одну из связей сократить логикой запроса до 1:N

Там всё гораздо хуже, даже UNION ALL есть... А нельзя это ограничение просто принять как данность в контексте вопроса?)

Вообще, формально, какой-нибудь способ, скорее всего, есть... а толку (эффективным он и близко не будет)? ;)

думал уже в json писать только k:v самих характеристик, т.е. {"brand":"samsung"}, а в другой табличке хранить всю инфу по характеристике со всеми её значениями, и локализациями/интернационализациями/мета информацией. Например, цвет можно писать тупо текстом на двух языках, но намного красивей когда на сайте есть цветовой "пиптик", сразу приятней выбирать фильтры.

короче, уже второй день думаю над реализацией, и не могу продвинуться никуда. за JSON зоопарком следить надо, а за таблицами (6NF) и прочим писать кучу бойлерплейта.

и типизация.. а ещё группировка фильтров, например у товара указан "Объем оперативной памяти: 6ГБ", а в фильтрах можно указать 6-8ГБ, т.е. фильтр - это уже комбинация из двух значений.

короче, уже второй день думаю над реализацией, и не могу продвинуться никуда. за JSON зоопарком следить надо, а за таблицами (6NF) и прочим писать кучу бойлерплейта.

А то Вы кучу boilerplate обычно не пишете (для обычных полей). ;) Всё равно что-то писать придётся, и какой-то подход к этому у Вас, скорее всего, уже есть.

А то Вы кучу boilerplate обычно не пишете (для обычных полей). ;) Всё равно что-то писать придётся, и какой-то подход к этому у Вас, скорее всего, уже есть.

да нет, у меня MVVM

я стараюсь даже null поля не иметь

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

хотя, я орм тут юзать не буду

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

да нет, у меня MVVM

(брюжжит) Понапридумали всякой фигни, проклятая молодежь! ;) А подробнее можете рассказать? Вот, например, добавляете вы поле в таблицу, и для того, чтобы оно попало в view/model, Вы делаете что?

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

Про "накосячить" — запросто. А в чём заключаются быстрота и удобство?

и типизация.. а ещё группировка фильтров, например у товара указан "Объем оперативной памяти: 6ГБ", а в фильтрах можно указать 6-8ГБ, т.е. фильтр - это уже комбинация из двух значений.

Так такой фильтр — в самом деле комбинация двух значений, нет?

(брюжжит) Понапридумали всякой фигни, проклятая молодежь! ;) А подробнее можете рассказать? Вот, например, добавляете вы поле в таблицу, и для того, чтобы оно попало в view/model, Вы делаете что?

зависит от дизайна базы, но в данном случае я делаю под себя, а не под массовый рынок, а значит мне придется написать миграцию, и в представлении просто отрендерить данный столбец, input допустим. Дальше, зависит от логики, если ОРМ - тогда больше ничего. Если нет ОРМ, тогда поправить логику выборки, сохранения.

Про "накосячить" — запросто. А в чём заключаются быстрота и удобство?

удобство вот так делать ... WHERE feature @> '{"brand":"samsung","cores":8}'

зависит от дизайна базы, но в данном случае я делаю под себя, а не под массовый рынок, а значит мне придется написать миграцию, и в представлении просто отрендерить данный столбец, input допустим. Дальше, зависит от логики, если ОРМ - тогда больше ничего. Если нет ОРМ, тогда поправить логику выборки, сохранения.

И это Вы не называете boilerplate, почему-то...