Рассмотрим следующие таблицы
Table "public.Foo"
Column | Type |
------------------+-----------------------------+
foo_id | integer | PK
bar_id | integer | FK to bars
....
Table "public.Bar"
Column | Type |
------------------+-----------------------------+
bar_id | integer | PK
....
Table "public.very_big"
Column | Type |
------------------+-----------------------------+
foo_id | integer
....
Бар отображается в Foo таким образом, что в баре много Foos.Есть <50 баров, каждый из которых имеет сотни Foos.Затем у меня есть отдельная таблица довольно большого размера, более 200 миллионов строк, которая ссылается на Foos (среди других таблиц), создавая большой составной первичный ключ, который приводит к большому размеру таблицы. </p>
В идеальном миреЯ хотел бы разделить very_big на bar_id, не добавляя столбец для bar_id, просто используя ссылку foo_id.Это дало бы хорошее количество разделов, порядка 1-50, в то время как разделение на foo_id напрямую составило бы тысячи, что рекомендуется в документации .
В некотором смысле этоидеальный мир - это раздел списка, основанный на объединении.Судя по документации, мне кажется, что это невозможно.Это также поднимает некоторые сложные вопросы, например, что происходит с данными в одном разделе, если отношение foo-bar изменяется таким образом, что данные должны будут перемещать разделы?Из-за этого это кажется невозможным / не имеет смысла.
Одной из альтернатив является использование определенного вручную списка разделов.Это приведет к тому, что каждый определенный вручную диапазон будет иметь порядка 300-500 значений.Некоторые минусы этого подхода: 1) если ссылки изменяются между foo и bar, как обсуждалось выше, раздел полностью разрушен (я не предвижу этого, иначе я бы не стал рассматривать это решение, но это все же обратная сторона) 2)Возможно, что большие, несмежные определения разделов списка из 300-500 значений будут иметь низкую производительность для планировщика запросов postgres.3) У недавно добавленных Foos не будет места, куда можно перейти на основе предварительно определенных списков, так как они не будут добавлены в определение раздела.
Другой альтернативой является подхватить его и добавить столбец.от bar_id до very_big, но это ненормально и избыточно.
Возможно ли разделение списка на основе объединения?(Я думаю, что нет)
Если нет, то есть ли последствия для производительности несмежных разделов на основе списка порядка 100+?(Не уверен, но здесь есть и другие затраты)
Существуют ли другие варианты решения этой проблемы, которые я потенциально пропускаю?Я планирую перейти к «денормализованному» решению на данный момент и добавить bar_id к very_big и определить раздел на основе этого
Спасибо