Сколько табличных разделов слишком много в Postgres?

Я разбиваю очень большую таблицу, содержащую временные данные, и учитывая, какой гранулярностью я должен сделать разделы. Документация Postgres утверждает, что "большое количество разделов, вероятно, значительно увеличит время планирования запроса" и рекомендует использовать разметку с "до, возможно, сто" .

Предполагая, что моя таблица хранит десять лет данных, если я разбиваю по неделям, у меня будет более 500 разделов. Прежде чем я это исправлю, я хотел бы лучше понять, какое влияние имеет количество разделов на время планирования запроса. Кто-нибудь оценил это, или кто-нибудь понимает, как это работает внутри страны?

Ответ 1

Планировщик запросов должен выполнять линейный поиск информации ограничения для каждого раздела таблиц, используемых в запросе, чтобы выяснить, какие из них действительно задействованы, - те, которые могут иметь строки, необходимые для запрошенных данных. Количество планов запросов, которые планирует планировщик, растет экспоненциально по мере того, как вы присоединяетесь к другим таблицам. Таким образом, точное место, где этот линейный поиск добавляет достаточно времени для беспокойства, действительно зависит от сложности запроса. Чем больше объединяется, тем хуже вас это поразит. Показатель "до ста" пришел к выводу, что время планирования запросов сводилось к нетривиальному времени даже при более простых запросах вокруг этой точки. В частности, в веб-приложениях, где важна латентность времени ответа, проблема; таким образом, предупреждение.

Можете ли вы поддержать 500? Конечно. Но вы будете искать каждый из 500 контрольных ограничений для каждого плана запроса, включающего эту таблицу, рассмотренную оптимизатором. Если время планирования запросов не беспокоит вас, тогда, возможно, вам все равно. Но большинство сайтов не любят долю времени, затрачиваемого на планирование запросов, с таким количеством разделов, что является одной из причин того, что ежемесячное разбиение является стандартом для большинства наборов данных. Вы можете легко хранить 10-летние данные, раздельно размещенные ежемесячно, прежде чем вы начнете переходить туда, где начнут появляться накладные расходы на планирование.

Ответ 2

"большое количество разделов, вероятно, значительно увеличит время планирования запроса" и рекомендует использовать разметку с "до стати" разделов.

Поскольку каждый дополнительный раздел обычно привязан к проверке ограничений, и это заставит планировщика задаться вопросом, какой из разделов необходимо запросить. В лучшем случае планировщик идентифицирует, что вы только нажимаете один раздел и полностью избавляетесь от шага append.

В терминах строк, и, как указывали DNS и Seth, ваше перемещение будет отличаться в зависимости от оборудования. Вообще говоря, не существует существенной разницы между запросом таблицы строк 1M и таблицей строк 10M, особенно если ваши жесткие диски позволяют быстро получить произвольный доступ и сгруппированы (см. Инструкцию cluster), используя индекс, чаще всего попадают.

Ответ 3

Каждый раздел таблицы занимает индексный дескриптор файловой системы. "Очень большой" - относительный термин, который зависит от характеристик вашей файловой системы. Если вам нужны явные тесты производительности, вы, вероятно, можете посмотреть различные тесты производительности почтовых систем из вашей ОС и FS по выбору. Вообще говоря, я бы не стал беспокоиться об этом, пока вы не попадете в десятки тысяч до сотен тысяч табличных пространств (используя dirhash на FreeBSD UFS2 победит). Также обратите внимание, что это же ограничение относится к DATABASES, TABLES или любому другому объекту базы данных, поддерживаемому файловой системой, в PostgreSQL.

Ответ 4

Если вы не хотите доверять разработчикам PostgreSQL, которые написали код, я рекомендую вам просто попробовать его самостоятельно и запустить несколько примерных запросов с объяснением анализа и временем их использования с использованием разных схем разделов. В любом случае ваша конкретная конфигурация оборудования и программного обеспечения, вероятно, будет доминировать над любым ответом.

Я предполагаю, что кеш оптимизации строк, который использует оптимизатор запросов для определения того, какие соединения и ограничения для использования хранятся в каждом разделе, поэтому, вероятно, необходимо загрузить и прочитать части каждого раздела для планирования запроса.