Битва при MERGE. Хроника с выводами и моралью

[vyegorov]

Актуальность разработки и качество её исполнения — две большие разницы. Когда комитеры указывают на недоработки или даже неоднозначности решений в предложенном патче — надо либо доказывать, либо принять их точку зрения и изменить решение. Именно поэтому новый функционал, даже самый актуальный, так тяжело входит. Нахожу это полезным для проекта.
Выскажу своё личное мнение, что INCLUDE-индексы получали хорошие разборы от того же Питера Гейгана и именно поэтому потребовали много времени — не самый простой патч. (Со стороны мне показалось, что были моменты когда Postgres Pro не уделяли патчу достаточно времени.)
Меня, как админа, расстраивает другое — не принимаются патчи, которые упрощают мониторинг базы (отслеживание event-ов, например) с аргументацией о падении производительности на пару процентов.

[Igor_Le]

«достаточно времени» — понятие относительное )
По поводу «другое» — у меня впечатление, что сейчас обсуждений, по крайней мере, этих тем в сообществе всё больше и больше.

[Igor_Le]

а вот такую штуку не видели, кстати? habr.com/post/413411

[vyegorov]

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

[chemtech]

Может сообществу Postgresql перенять опыт сообщества Kubernetes. Там фичи со статусом альфа находится в активной разработке, бета означает, что он будет иметь гарантии совместимости. Т.е. например для активации альфа фич, нужно компилировать Postgresql с определенными опциями. Для активации бета фич нужно выставить специальный флаг в sysconfig или default конфиге. Так можно внедрять фичи быстрее и не опасаться что широкий круг пользователей Postgresql наткнутся на эту фичу. Т.е. фичу будут активировать только знающие люди — например разработчики

[Igor_Le]

уж больно разные проекты…

[VolCh]

Вот эта необходимость «пробивать» частенько отбивает желание что-то делать. Если уж внутри таких команд такие битвы, то что говорить о патчах «с улицы»?

[Igor_Le]

С одной стороны — да. С другой: особенно трудно пробивать большие и принципиальные патчи потому, что они затрагивают много подсистем, требуют изменений в других файлах. Если патч маленький, но нужный, то вполне может пройти малой кровью.

[Kamareka]

«По этой причине MERGE не может работать с секционированными таблицами [Это цитируется по описанию MERGE в Oracle, наиболее полном.»
Это неверно. Никаких подобных ограничений merge в Oracle нет.

[Igor_Le]

Да, ошибся, спасибо. Это из другого документа, не ораклового.

[Igor_Le]

сейчас поправлю.

[PaulIsh]

Очень нужная SQL конструкция. Любопытно было узнать, что анализ реализаций MERGE проводится по коммерческим СУБД, а open source проект Firebird в рассмотрении отсутствует.

Как раз столкнулся с ее отсутствием при миграции с Firebird.
Часть запросов действительно можно переписать через

INSERT ON CONFLICT DO UPDATE

Правда все запросы так не переписать. Переписать вторую часть запросов помогла специфическая для Postgres конструкция

UPDATE FROM

Надеюсь что после длительных дебатов эта возможность все-такие появится в Postgres 12.

[Igor_Le]

В каком-то виде MERGE в 12 наверняка появится.
Почему-то ни в одном обсуждении в сообществе не видел упоминания Firebird в контексте MERGE.
А какие запросы удалось втиснуть в ON CONFLICT, а какие отправились в UPDATE FROM? По какому критерию?

[PaulIsh]

Запросы, которые обновляли/добавляли все поля переехали на ON CONFLICT. Запросы, которые обновляли часть полей из SELECT ушли в UPDATE FROM. Для них ON CONFLICT не работал из-за наличия not null проверок.

[Igor_Le]

понятно. спасибо!

[edo1h]

а open source проект Firebird в рассмотрении отсутствует.

он вообще не так уж часто упоминается, хотя вроде бы весьма зрелый проект

при миграции с Firebird

если не секрет, почему мигрировали, какие у firebird сильные и какие слабые стороны?

[PaulIsh]

Для нас сильными сторонами Firebird являлись (являются):

• Простота установки и распространения
• Бесплатный для exUSSR IBExpert — пожалуй лучший инструмент для работы с СУБД, который я видел
• Хорошая поддержка стандарта
• Отличная поддержка в Delphi
• Механизм транзакций, где в рамках подключения можно иметь длинную читающую и короткие пишущие транзакции

Слабые стороны для нас:

• Медленное развитие. Версию 3 после выхода 2.5 ждали годы.
• Маленькое сообщество, в связи с чем поддержка версии 3 в PHP задержалась на месяцы после выхода, а в NodeJS, кажется, до сих пор нормально не реализована.
• Нет многих вещей, стандартных для крупных СУБД в настоящее время, в том числе репликации, партиционирования.
• Какой-то свой подход к блокировкам записей, приводящий к периодически возникающим ошибкам с блокировкой записей соседними транзакциями

[edo1h]

чем закончилась история?