Тут согласен, к сожалению, у меня нет обычной линукс машины, чтобы протестировать более чисто. Так что да, на время выполнения запросов лучше не смотреть.
С остальным не согласен, я хотел сравнить логику работы обычного партиционирования и pg_pathman на большой бд, то есть на той бд для которой нужно партиционирование. Для этого нужно было смоделировать большую бд. У неё есть собственно сама большая бд (у меня партиционированные таблицы заняли почти 6 гигов) и мальнький кэш (shared_buffers = 512M) по сравнению с самой бд. В таких бд обычно есть дефицит кэша бд, и их узкое место — работа с диском.
Процессорное время там может быть узким местом, только если бд неправильно спроектирована, ну или в каких-то сильно специфических случаях.
Хотя, можно было бы, конечно, оперативу у виртуалки убавить и размер shared_buffers уменьшить. И индексы, возможно, зря создал, но без них схема на нормальную бд была бы вообще не похожа.
Конечно, страничные чтения тоже важны, но их нельзя напрямую использовать для оценки стоимости выполнения запросов.
Первым и главным критерием для запросов в статье является сработало ли отсечение партиций или нет. А в качестве второго критерия использовать чтения страниц, я считаю, даже нужно. При выполнении запроса по партиционным таблицам, некоторая часть данных конечно будет в кэше, но какая это будет часть зависит от количества просматриваемых страниц. То есть чем меньше страниц смотрим — тем меньше читаем с диска.
Тут ещё надо учесть, что разница в два раза количества страниц здесь, она на большой бд с 300-ми партициями легко может превратиться в 200 и более раз.
Можно было бы не сбрасывать файловый кеш, а наоборот, рассмотреть ситуацию (в вакууме), когда все данные попали в shared_buffers.
Ну эта ситуация не типична для большой бд. И если бы вся бд уместилась в буфере, то непартиционированная схема была бы быстрее обоих рассмотренных вариантов. :) Но так как бд была больше кэша, то всю её туда уместить не получилось бы. Сделать же одинаковое начальное содержимое кэша для всех запросов было сложно, поэтому я просто перезагружал постгрес, чтобы в буфере ничего не было.
Раз уж зашла речь о количестве секций: с самого начала наш проект стремился оптимизировать кейс с большим количеством секций. Многие оптимизации опираются на наш кеш, по которому осуществляется бинарный поиск подходящих партиций (или поиск по хешу ключа партицирования).
Я очень рад, что такая оптимизация в pg_pathman есть, но я про неё не знал и поэтому не протестировал.
На большом количестве партиций она может сэкономить процессорное время, это хорошо.
Кстати, я ж протестировал две константы на 30 партициях и план таки не изменился, вот что обидно.
Но на это надо будет багу постгресовцам написать — у них с планированием limit проблемка похоже есть. Будет свободное время — напишу.
Время исполнения первого запроса не очень показательно, т.к. инициализируется syscache постгреса и наш собственный кеш (как и мы, он тоже ленивый :) Можно было бы показать результат прогона запросов при помощи pgbench, чтобы сгладить выбросы. Кроме того, можно применить prepared statements для исключения времени планирования. В таком случае запросы, которые pg_pathman дольше планировал, заиграют новыми красками.
Вот поэтому на время я особо и не смотрел, а смотрел на страницы. Что касается pgbench, то опять же, это не типичный случай когда всё уже в кэше.
Главное это срабатывание отсечения партиций — оно даст основной эффект, все остальные преимущества оптимизаций pg_pathman будут не таким большим, но приятным бонусом.
Возможно, но судя по этому CREATE TABLE book_history_2016_09
PARTITION OF book_history
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');
и по этому Текущие ограничения партиционирования в 10 это пока красивая надстройка над наследованием плюс механизм раскидывания вставляемых записей. Глобальных индексов, ключей и уж тем более правильного планирования и отсечения партиций в запросах там ещё нет. Это всё надо будет пилить и пилить. То есть счастье похоже будет, но не скоро.
Тут согласен, к сожалению, у меня нет обычной линукс машины, чтобы протестировать более чисто. Так что да, на время выполнения запросов лучше не смотреть.
С остальным не согласен, я хотел сравнить логику работы обычного партиционирования и pg_pathman на большой бд, то есть на той бд для которой нужно партиционирование. Для этого нужно было смоделировать большую бд. У неё есть собственно сама большая бд (у меня партиционированные таблицы заняли почти 6 гигов) и мальнький кэш (shared_buffers = 512M) по сравнению с самой бд. В таких бд обычно есть дефицит кэша бд, и их узкое место — работа с диском.
Процессорное время там может быть узким местом, только если бд неправильно спроектирована, ну или в каких-то сильно специфических случаях.
Хотя, можно было бы, конечно, оперативу у виртуалки убавить и размер shared_buffers уменьшить. И индексы, возможно, зря создал, но без них схема на нормальную бд была бы вообще не похожа.
Первым и главным критерием для запросов в статье является сработало ли отсечение партиций или нет. А в качестве второго критерия использовать чтения страниц, я считаю, даже нужно. При выполнении запроса по партиционным таблицам, некоторая часть данных конечно будет в кэше, но какая это будет часть зависит от количества просматриваемых страниц. То есть чем меньше страниц смотрим — тем меньше читаем с диска.
Тут ещё надо учесть, что разница в два раза количества страниц здесь, она на большой бд с 300-ми партициями легко может превратиться в 200 и более раз.
Ну эта ситуация не типична для большой бд. И если бы вся бд уместилась в буфере, то непартиционированная схема была бы быстрее обоих рассмотренных вариантов. :) Но так как бд была больше кэша, то всю её туда уместить не получилось бы. Сделать же одинаковое начальное содержимое кэша для всех запросов было сложно, поэтому я просто перезагружал постгрес, чтобы в буфере ничего не было.
Я очень рад, что такая оптимизация в pg_pathman есть, но я про неё не знал и поэтому не протестировал.
На большом количестве партиций она может сэкономить процессорное время, это хорошо.
Кстати, я ж протестировал две константы на 30 партициях и план таки не изменился, вот что обидно.
Но на это надо будет багу постгресовцам написать — у них с планированием limit проблемка похоже есть. Будет свободное время — напишу.
Вот поэтому на время я особо и не смотрел, а смотрел на страницы. Что касается pgbench, то опять же, это не типичный случай когда всё уже в кэше.
Главное это срабатывание отсечения партиций — оно даст основной эффект, все остальные преимущества оптимизаций pg_pathman будут не таким большим, но приятным бонусом.
Спасибо за комментарий.
CREATE TABLE book_history_2016_09
PARTITION OF book_history
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');
и по этому Текущие ограничения партиционирования в 10 это пока красивая надстройка над наследованием плюс механизм раскидывания вставляемых записей. Глобальных индексов, ключей и уж тем более правильного планирования и отсечения партиций в запросах там ещё нет. Это всё надо будет пилить и пилить. То есть счастье похоже будет, но не скоро.