Комментарии 15
Хм, ваши доработки выглядят как что-то очень нужное и полезное для PostgreSQL. В связи с этим хотелось бы услышать хотя бы пару слов о причинах, по которым разработчики PostgreSQL не захотели воспользоваться вашими доработками. Не успели? Или у них там прямо какие-то идеологические возражения?
Патч очень объемный, и затрагивает ядро СУБД - такие патчи сложно ревьюить, и на это нужно много времени. Определенную обратную связь мы от них получили, и переработали патчи в соответствии с ней, но этой связи, к сожалению недостаточно, и интерес сообщества смещен к более простым доработкам. Похоже, релизный комитет опасается вливать такие серьезные изменения. Ну и сейчас, вполне возможно, у отдельных членов сообщества есть и политические мотивы.
Патч очень объемный
Возможно ли его разделить на части и внедрять в СУБД постепенно? Большого слона нужно есть по частям. Разделяй и влавствуй )
Мы поделили его на несколько логических частей, и все равно пока еще ничего не принято. Поэтому нами принято решение попробовать переделать так, чтобы эту доработку можно было выложить как расширение, с минимальными изменениями ядра.
Это все очень печально (то что такие революционные доработки пгпро не принимают) и доказывает что ванила postgres это не чистый опенсорс, а лишь игра в него.
привет, ничего не мешает сделать форк postgres
и назвать ветку к примеру postgresx
раз это не сделано, значит эти изменения предлагаемые командой Postgres Professional не перевешивают чашу весов работы ванильной команды
Много форков не значит хорошо, вокруг продукта должно быть комьюнити, а сам продукт должны развивать профессионалы. Пгпро развивают свою реализацию postgres и в то же время активно улучшают ванилу, это очень радует. Но в чистом опенсорсе, по-моему мнению, решение о внедрении той или иной фичи должны принимать все участники сообщества (контрибьюторы), а не некий core team из 7 человек, 3 из которых работают на одну компанию.
Мы отказались от этого варианта. Сложность в том, что если влить эту доработку в наш форк сейчас, а потом она все же войдет в ванильный мастер, но в измененном виде - придется переделывать уже существующий и использующийся механизм, что, скорее всего, станет дополнительным источником ошибок. Изменения в ванильном мастере идут постоянно, и, например, за последние полгода - весьма значительные, есть неиллюзорные шансы что ветки разойдутся так, что собирать это через, скажем, год, будет крайне сложно. Мы сейчас работаем над тем, чтобы была возможность влить эту доработку с минимальными модификациями ядра. Это, конечно, даст определенный оверхед - но избавит от упомянутых выше проблем.
Думаю ситуация похожа на тему с 64 битным счетчиком транзакций. Проблема касается "не только лишь всех", а работы по части ревью будет много. Вот и откладывают.
Спасибо, не знал про такое. Счас понимаю, что мы пока даже близко не подходили к пределу наполнения тост-таблицы, но на будущее пометочку сделал...
Практика (и тикеты =)) показывают, что в больших базах обычно счетчик toast value id заканчивается раньше табличного пространства, и вот тут начинаются чудеса с поведением СУБД
Жарим TOAST в PostgreSQL