Спасибо большое за вашу статью, сами мы страшно ленивые и пишем редко. А вы и реальные кейсы описали, и вердикт хороший вынесли :)
Как один из разработчиков pg_pathman, хочу обозначить несколько важных моментов:
1) Методика тестирования все-таки не идеальна. Во-первых, виртуализация и дисковый кеш Windows оказывают свое влияние, поэтому времени исполнения запросов доверять мы не можем, а это очень важный критерий. Конечно, страничные чтения тоже важны, но их нельзя напрямую использовать для оценки стоимости выполнения запросов. Необходимо также учитывать, что горячие партиции практически не будут вымываться из shared_buffers, при вычислении join'ов будут тратиться ресурсы CPU на проекцию и сборку кортежей, не учитывается стоимость вычисления функций и многие другие вещи.
2) Можно было бы не сбрасывать файловый кеш, а наоборот, рассмотреть ситуацию (в вакууме), когда все данные попали в shared_buffers. Это позволило бы дать представление о преимуществах pg_pathman при отсечении лишних секций.
3) Раз уж зашла речь о количестве секций: с самого начала наш проект стремился оптимизировать кейс с большим количеством секций. Многие оптимизации опираются на наш кеш, по которому осуществляется бинарный поиск подходящих партиций (или поиск по хешу ключа партицирования). Эти преимущества не получится показать на маленьком числе партиций, потому что в таком случае даже брутфорс по check constraints (который применяет ванильный постгрес) окажется вполне приемлемым решением.
4) Время исполнения первого запроса не очень показательно, т.к. инициализируется syscache постгреса и наш собственный кеш (как и мы, он тоже ленивый :) Можно было бы показать результат прогона запросов при помощи pgbench, чтобы сгладить выбросы. Кроме того, можно применить prepared statements для исключения времени планирования. В таком случае запросы, которые pg_pathman дольше планировал, заиграют новыми красками.
Как один из разработчиков pg_pathman, хочу обозначить несколько важных моментов:
1) Методика тестирования все-таки не идеальна. Во-первых, виртуализация и дисковый кеш Windows оказывают свое влияние, поэтому времени исполнения запросов доверять мы не можем, а это очень важный критерий. Конечно, страничные чтения тоже важны, но их нельзя напрямую использовать для оценки стоимости выполнения запросов. Необходимо также учитывать, что горячие партиции практически не будут вымываться из shared_buffers, при вычислении join'ов будут тратиться ресурсы CPU на проекцию и сборку кортежей, не учитывается стоимость вычисления функций и многие другие вещи.
2) Можно было бы не сбрасывать файловый кеш, а наоборот, рассмотреть ситуацию (в вакууме), когда все данные попали в shared_buffers. Это позволило бы дать представление о преимуществах pg_pathman при отсечении лишних секций.
3) Раз уж зашла речь о количестве секций: с самого начала наш проект стремился оптимизировать кейс с большим количеством секций. Многие оптимизации опираются на наш кеш, по которому осуществляется бинарный поиск подходящих партиций (или поиск по хешу ключа партицирования). Эти преимущества не получится показать на маленьком числе партиций, потому что в таком случае даже брутфорс по check constraints (который применяет ванильный постгрес) окажется вполне приемлемым решением.
4) Время исполнения первого запроса не очень показательно, т.к. инициализируется syscache постгреса и наш собственный кеш (как и мы, он тоже ленивый :) Можно было бы показать результат прогона запросов при помощи pgbench, чтобы сгладить выбросы. Кроме того, можно применить prepared statements для исключения времени планирования. В таком случае запросы, которые pg_pathman дольше планировал, заиграют новыми красками.