миф видимо. Значит тут у меня более релевантный опыт.
> А вот это кардинально не совпадает с тем, что я видел в подобных случаях
Я сейчас сниму с прод базы стату, где таблицу партиционировали раньше по три месяца, а теперь по месяцу, самому интересно. По вашей телрии корреляция должна вырасти кардинально.
>практически не имеет значения
Почитайте про partition pruning, пожалуйста.
В общем, похоже у меня больше опыта про использование партишнов для перформанса (чтобы перформанс не деградировал при росте данных) поэтому можем закончить дискуссию.
Скину стату только, как гляну (самому интересно).
> Лолшто? Partition prunning это миф видимо. То, что я написал. Partition pruning — это попытка "отбить" часть потерянной производительности! > Значит тут у меня более релевантный опыт. Почему Вы так решили? > По вашей телрии корреляция должна вырасти кардинально. От нагрузки зависит! Если это insert-only — ничего существенного не увидите, конечно. > Почитайте про partition pruning, пожалуйста. Не считайте себя умнее всех, пожалуйста! Или сходите в -hackers, посоветуйте вот этому "глупому человеку" тоже почитать про partition pruning (а то что он всё только участвует в его реализации): https://www.postgresql.org/message-id/31605.1586112900%40sss.pgh.pa.us Я поцитирую оттуда, для ясности: Your default expectation with a table with many partitions should be that queries will have to hit all those partitions and it will take a long time. In general though, partitioning should be a last resort when you've got so much data that you have no other choice. > В общем, похоже у меня больше опыта про использование партишнов для перформанса (чтобы перформанс не деградировал при росте данных) поэтому можем закончить дискуссию. Да как хотите. Мне этот фарс тоже надоел.
Обсуждают сегодня