Можно ли создать раздел списка в PostgreSQL на основе объединения ключа списка разделов? - PullRequest
0 голосов
/ 18 мая 2018

Рассмотрим следующие таблицы

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 и определить раздел на основе этого

Спасибо

...