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

Question

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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