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

NOTNULL = IS NOT NULL ?

одно и то же. notnull краткий алиас от pg, is not null - по sql стандарту

одно и то же. notnull краткий алиас от pg, is not null - по sql стандарту

Тогде буду писать воторой вариант, раз это SQL стандарт

Тогде буду писать воторой вариант, раз это SQL стандарт

Если вам нужна переносимость между базами, то да. Но я не верю в нормальную переносимость сложных запросов, а is not null реально длиннее)

Если вам нужна переносимость между базами, то да. Но я не верю в нормальную переносимость сложных запросов, а is not null реально длиннее)

Если только в oracle, но лет через 10 )))

Спасибо за ответы :)

Ничего не понимаю: делаю запрос в DataGrip select * from table where id between 1 and 1000. Первый раз квери срабатывает за несколько секунд. Второй раз, когда выбираю "экспорт в файл", она запускается и висит в pg_stat_activity уже больше получаса. Второй раз подряд такое.

хочу маленький кусок БД для staging и тестирования вытащить

Если только в oracle, но лет через 10 )))

За этот срок пг всех победит и notnull примут в стандарт (нет)))

Ничего не понимаю: делаю запрос в DataGrip select * from table where id between 1 and 1000. Первый раз квери срабатывает за несколько секунд. Второй раз, когда выбираю "экспорт в файл", она запускается и висит в pg_stat_activity уже больше получаса. Второй раз подряд такое.

Медленный диск? ?

Медленный диск? ?

уже разобрался, там индекса не было)

На айдишнике!??

На айдишнике!??

это таблица типа аудита - id, timestamp, data, поэтому pkey не имело смысла делать, достаточно ж индексов

DataGrip в гуе рисует только первых 500 строк

Если вам нужна переносимость между базами, то да. Но я не верю в нормальную переносимость сложных запросов, а is not null реально длиннее)

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

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

ну а вдруг это помимо экономии 2,5 байт трафика еще позволяет серверу построить более оптимальный план выполнения!? кто знает

О да

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

Ну что вы так, я не навязываю никаких решений. Сам, кстати, пишу is not null, но в notnull ничего не вижу плохого. Все равно перенести специфичную реализацию SQL в pg без переделки всего и вся нереально

мне удобно, когда можно прочитать SQL как английский текст

Ну что вы так, я не навязываю никаких решений. Сам, кстати, пишу is not null, но в notnull ничего не вижу плохого. Все равно перенести специфичную реализацию SQL в pg без переделки всего и вся нереально

Если писать, как вы предлагаете, то да, не перенесете, если же по стандарту, то все переносится максимум через замену

Если писать, как вы предлагаете, то да, не перенесете, если же по стандарту, то все переносится максимум через замену

Расскажите мне про with recursive, generate_series/специфичные jsonb функции, lateral (его нет в mysql). Может, я пишу не так плохо, а вы не очень знаете тонкости, ммм?;)

Расскажите мне про with recursive, generate_series/специфичные jsonb функции, lateral (его нет в mysql). Может, я пишу не так плохо, а вы не очень знаете тонкости, ммм?;)

а тебе голосом с командой про SQL говорить часто приходится? :)

а тебе голосом с командой про SQL говорить часто приходится? :)

Не понял тебя)

Расскажите мне про with recursive, generate_series/специфичные jsonb функции, lateral (его нет в mysql). Может, я пишу не так плохо, а вы не очень знаете тонкости, ммм?;)

Речь идет не про специфичные команды и не про mysql. Речь идет про миграцию

Не понял тебя)

у тебя в проекте кроме тебя вообще пишут на SQL? :)

у тебя в проекте кроме тебя вообще пишут на SQL? :)

Да, ещё один человек

и он рядом сидит и в монитор посмотреть может? :)

и он рядом сидит и в монитор посмотреть может? :)

Да, а что?

а тебе голосом с командой про SQL говорить часто приходится? :)

новая передача на тнт: SQL-голос! или это на первом?..

я просто догадываюсь, что кто-то может написать вместо продиктованного NOTNULL - NOT NULL и убить пять минут на поиск ошибки, а то и больше

а потом объяснять, почему надо писать is distinct from в три слова, а notnull в одно - вообще застрелиться :)

я просто догадываюсь, что кто-то может написать вместо продиктованного NOTNULL - NOT NULL и убить пять минут на поиск ошибки, а то и больше

А ты часто диктуешь голосом кому-то команды sql?) Каждый пишет что-то своё. Если нужно отрефакторить, вытяни ветку и у себя посмотри

Речь идет не про специфичные команды и не про mysql. Речь идет про миграцию

Речь шла про переносимость между разными СУБД. Миграциям же вообще до фонаря, notnull или is not null,система контроля версий это разрулит

Какой то "аргументный аргумент"

Какой то "аргументный аргумент"

Я пока кроме оскорблений от тебя ничего не услышал, аргументов тоже

Аргумент один, как я писал выше, не стоит предлагать отход от стандарта

Да и оскорблений пока тоже не было

Аргумент один, как я писал выше, не стоит предлагать отход от стандарта

Стандарт - общие рекомендации, реализации у каждого производителя свои

Стандарт - это свод правил

А вот у вас, это рекомендация

Да и оскорблений пока тоже не было

"Писать через жопу" - это что тогда, ммм?

"Писать через жопу" - это что тогда, ммм?

Констатация факта

А вот у вас, это рекомендация

With recursive тоже рекомендация?

Констатация факта

А по-моему ты просто хам

Причем здесь это?

Причем здесь это?

Этого в стандарте нет

Этого в стандарте нет

Прекрасно, а is not null есть и предлагать писать notnull при этом бред

Прекрасно, а is not null есть и предлагать писать notnull при этом бред

Если ты все равно пишешь специфичный код, то это дело вкуса. Аргумент про переносимость не работает

Все понятно, пишите как хотите. Желаю вам потом разгребать это

Все понятно, пишите как хотите. Желаю вам потом разгребать это

Благодарю, пока справляюсь

Всем привет. А что то не могу найти на сайте Professional Postgres цен ни на что. Сколько Postgresq Pro Enterprise стоит и сколько Pro Standart ивестно?

https://postgrespro.ru/products/postgrespro/certified в середине табличка

про остальное, подозреваю, как договоришься :)

солидный постгрес для солидных господ

кстати https://postgrespro.ru/products/postgrespro/enterprise — увлекательное чтение. давно так не смеялся

"Сжатие данных затрудняет несанкционированный доступ к информации непосредственно на диске" — а?

приходишь ты, крадёшь файлы релейшена - а они жатые, и обычный постгрес их не читает.

облом, да

приходишь ты, крадёшь файлы релейшена - а они жатые, и обычный постгрес их не читает.

То есть есть смысл воровать файлы только солидным клиентам с энтерпрайз постгресом;)

кстати https://postgrespro.ru/products/postgrespro/enterprise — увлекательное чтение. давно так не смеялся

энтерпрайз смотрит на тебя недоуменно и немного с осуждением

солидный постгрес для солидных господ

аж посмотрел как интересно стало. десятка в месяц!? куда уж солидней, да ))

ERROR: S client not available

да шучу я, шучу. мы все взрослые люди и всё понимаем

Дешевле в разы чем оракл, энтерпразй не заметить, ему это как семки купить)

фишка в поддержке. а поддержка заранее не знает, на кого напорется, а SLA выдерживать должна

это не десктопный софт, в котором катит "ой, мы не знаем, давайте вам просто вернут ваши $99?"

ну если уж про сравнения говорить, оно конечно дешевле в разы чем оракл, но функционал-то тоже в разы отличается. да что там оракл, 90% из той таблицы есть в бесплатном mysql

о. SFCGAL вернули в pgdg94

вернули?

ну если уж про сравнения говорить, оно конечно дешевле в разы чем оракл, но функционал-то тоже в разы отличается. да что там оракл, 90% из той таблицы есть в бесплатном mysql

табличка обещает снизить эксплуатацию на 510% суммарно. Так-то! ?

shut up and take my money!

о. SFCGAL вернули в pgdg94

какая версия?

SFCGAL x86_64 1.2.2-1.rhel7 pgdg94

на днях вообще никакой на было, и у меня yum ругался

ой, это ж от 2015

тут просто 1.3.1 затегировали, который обещает отпилить от постгиса лишних обязательных зависимостей

Всем добрый день! Можно задать вопрос про применимость BRIN-индекса? У меня таблица с 1-2 гб данных. Большинство запросов включают where foo = 1 and bar = 2. Сейчас у меня BTree-индекс на (foo, bar). Поможет ли мне BRIN? На тестовых данных вроде особо не используется и BTree побеждает. Пробовал CLUSTER, без изменений. Кардинальность у foo порядка тысяч уникальных значений. Кардинальность bar - порядка пяти.

Кто может по лондисту подсказатЬ? как посмотреть в какую таблицу на слейв реплицируется моя таблица, у нее другое имя

Всем добрый день! Можно задать вопрос про применимость BRIN-индекса? У меня таблица с 1-2 гб данных. Большинство запросов включают where foo = 1 and bar = 2. Сейчас у меня BTree-индекс на (foo, bar). Поможет ли мне BRIN? На тестовых данных вроде особо не используется и BTree побеждает. Пробовал CLUSTER, без изменений. Кардинальность у foo порядка тысяч уникальных значений. Кардинальность bar - порядка пяти.

а сколько строк возвращается? возможно, у вас основные потери не на поиске по индексу, а на вытаскивании из heap значения (если строк много). если это так, то btree/brin - одинаково не помогут

Строк от 1 до 60 000. AVG - 3000.

Всем добрый день! Можно задать вопрос про применимость BRIN-индекса? У меня таблица с 1-2 гб данных. Большинство запросов включают where foo = 1 and bar = 2. Сейчас у меня BTree-индекс на (foo, bar). Поможет ли мне BRIN? На тестовых данных вроде особо не используется и BTree побеждает. Пробовал CLUSTER, без изменений. Кардинальность у foo порядка тысяч уникальных значений. Кардинальность bar - порядка пяти.

Не имеет смысла на таких маленьких таблицах. Почитай внимательно как работает этот индекс.

ну на среднем должно быть приемлемо. а можно explain analyze?

Denis https://pastebin.com/raw/JPpnHch4

в теории, быстрее может быть только index only scan по покрывающему индексу. если вы вытаскиваете идентификатор, то его тоже пожно самым крайним справа положить в индекс. и да, на 1-2гб btree будет самым эффективным вариантом.

Ясно, спасибо. А на каком объёме становится эффективным BRIN? Больше 10 Гб, как я понимаю?

Ясно, спасибо. А на каком объёме становится эффективным BRIN? Больше 10 Гб, как я понимаю?

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

У меня как раз таблица - партиция :) Я разрабатываю хранилище эвентов и стараюсь подобрать партиции, чтобы они были порядка 1-3 Гб.

У меня как раз таблица - партиция :) Я разрабатываю хранилище эвентов и стараюсь подобрать партиции, чтобы они были порядка 1-3 Гб.

сбалансированное дерево вам будет достаточно)

Всё ясно, спасибо! А можно ещё вопрос? Есть ли какой-либо толк держать даты в tsrange, если EXCLUDE USING GIST не используется и большинство запросов а-ля lower(range) >= '2016' and upper(range) < '2017'. Мне кажется, что никакой выгоды в моём случае tsrange не даёт, но может я чего-то не знаю?

Может кто нибудь сказать как достигается отказоустойчивость Postgresql, какие используются инструменты, требования к инфраструктуре. Интересет решение от Postgres Professional(можно платное). Про repmgr, patroni слышал.

Конкретнее, разбивка партиций у меня по lower(range), а по range выборка идёт уже после Index Cond по моему BTree-индексу, так что фильтуется в среднем те же 3000 записей.

Ясно, спасибо. А на каком объёме становится эффективным BRIN? Больше 10 Гб, как я понимаю?

brin - это такой индекс на случай "раз в год бы пригодилось поселектать по полю"