Использование хинтов может решить некоторые проблемы, но это сложная задачка, требующая от разработчика знаний о внутренних механиках СУБД и специфике работы приложения, и оно имеет и обратную сторону - сервер, действительно, может построить более оптимальный план, при ошибке хинт просто не сработает и сервер, опять же, будет использовать свои планы, а при изменении, к примеру, индексов придется переписывать хинты. Учитывая что хинт обычно пишется в каких-то очень неочевидных случаях - разбираться тому кто придет поддерживать код с хинтами часто бывает очень непросто.
Я не против хинтов - я много работал с ними, и хорошо знаю что это совсем не панацея.
Мы отказались от этого варианта. Сложность в том, что если влить эту доработку в наш форк сейчас, а потом она все же войдет в ванильный мастер, но в измененном виде - придется переделывать уже существующий и использующийся механизм, что, скорее всего, станет дополнительным источником ошибок. Изменения в ванильном мастере идут постоянно, и, например, за последние полгода - весьма значительные, есть неиллюзорные шансы что ветки разойдутся так, что собирать это через, скажем, год, будет крайне сложно. Мы сейчас работаем над тем, чтобы была возможность влить эту доработку с минимальными модификациями ядра. Это, конечно, даст определенный оверхед - но избавит от упомянутых выше проблем.
Мы поделили его на несколько логических частей, и все равно пока еще ничего не принято. Поэтому нами принято решение попробовать переделать так, чтобы эту доработку можно было выложить как расширение, с минимальными изменениями ядра.
Практика (и тикеты =)) показывают, что в больших базах обычно счетчик toast value id заканчивается раньше табличного пространства, и вот тут начинаются чудеса с поведением СУБД
Патч очень объемный, и затрагивает ядро СУБД - такие патчи сложно ревьюить, и на это нужно много времени. Определенную обратную связь мы от них получили, и переработали патчи в соответствии с ней, но этой связи, к сожалению недостаточно, и интерес сообщества смещен к более простым доработкам. Похоже, релизный комитет опасается вливать такие серьезные изменения. Ну и сейчас, вполне возможно, у отдельных членов сообщества есть и политические мотивы.
для каждой партиции отдельно
Использование хинтов может решить некоторые проблемы, но это сложная задачка, требующая от разработчика знаний о внутренних механиках СУБД и специфике работы приложения, и оно имеет и обратную сторону - сервер, действительно, может построить более оптимальный план, при ошибке хинт просто не сработает и сервер, опять же, будет использовать свои планы, а при изменении, к примеру, индексов придется переписывать хинты. Учитывая что хинт обычно пишется в каких-то очень неочевидных случаях - разбираться тому кто придет поддерживать код с хинтами часто бывает очень непросто.
Я не против хинтов - я много работал с ними, и хорошо знаю что это совсем не панацея.
Мы отказались от этого варианта. Сложность в том, что если влить эту доработку в наш форк сейчас, а потом она все же войдет в ванильный мастер, но в измененном виде - придется переделывать уже существующий и использующийся механизм, что, скорее всего, станет дополнительным источником ошибок. Изменения в ванильном мастере идут постоянно, и, например, за последние полгода - весьма значительные, есть неиллюзорные шансы что ветки разойдутся так, что собирать это через, скажем, год, будет крайне сложно. Мы сейчас работаем над тем, чтобы была возможность влить эту доработку с минимальными модификациями ядра. Это, конечно, даст определенный оверхед - но избавит от упомянутых выше проблем.
Там не все так просто. Я думаю, эти материалы войдут в еще одну статью, не такую объемную как эта, но не менее интересную
Мы поделили его на несколько логических частей, и все равно пока еще ничего не принято. Поэтому нами принято решение попробовать переделать так, чтобы эту доработку можно было выложить как расширение, с минимальными изменениями ядра.
Практика (и тикеты =)) показывают, что в больших базах обычно счетчик toast value id заканчивается раньше табличного пространства, и вот тут начинаются чудеса с поведением СУБД
Патч очень объемный, и затрагивает ядро СУБД - такие патчи сложно ревьюить, и на это нужно много времени. Определенную обратную связь мы от них получили, и переработали патчи в соответствии с ней, но этой связи, к сожалению недостаточно, и интерес сообщества смещен к более простым доработкам. Похоже, релизный комитет опасается вливать такие серьезные изменения. Ну и сейчас, вполне возможно, у отдельных членов сообщества есть и политические мотивы.