/report

@alex_solonenko: @afiskon @confguru @Komzpa @pasha_golub @obartunov

+

ну вот. я не успел понять дичь или нет :(

Доброй ночи кто может подсказать как перевести сервер slave в master на postgresql 12

?

Там вроде файл который отвечает за реплику надо убрать, и promote команду кинуть через pg_ctl

^

pg_ctl promote -D db-slave эту?

Пишет
pg_ctl: directory "db-slave" does not exist

Ну вот китайцы из highgo, японцы из Fujitsu, EDB... много кто занимается улучшайзингом партицирования, но работы там ещё выше крыши. И я не уверен, что вообще правильный подход. По крайней мере CitusDB, GreenPlum, Pg-XL пошли другим путём. Впрочем тогда партицирование вообще было в зачаточном состоянии.

Довольно странное ИМХО желание, противоречащее самой сути партицирования (уменьшения размера таблицы и индексов)

Полностью path к data colder попробуй указать

Хмм... а почему Вы думаете, что он вообще падает?
А вообще — можно протестировать (если любопытно, таблица-то с виду всё равно маленькая).

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

Применение локальных и глобальных индексов в том же oracle позволяет использовать секционирование значительно чаще

А почему Вы сомневаетесь, что это правильный подход (или в каком смысле он кажется неправильным)?

Ну не знаю... Вам видней. Если размер таблицы намного превышает размеры индекса (т.е. грубо говоря в таблицы много полей или есть blob-ы), то это имеет смысл. Если же размер индекса сравним с размером таблицы, то становится не понятным - заем тогда вообще было разрезать таблицу на части, чтоб потом прицепить к ней глобальный индекс, т.е. иметь общее дерево на всю таблицу. Впрочем возможно в Оракле это как-о умнее сделано. Не думал много про это...

> Без этого вряд ли получится сделать уникальность поля в рамках всей таблицы

Почему "не получится"? Можно добиться того же эффекта и без этого.
Но любое такое решение в любом случае "дорогое" по производительности, как его ни реализовывай.

> сделать fk из несекционированной таблицы, на секционированную

Это и сейчас работает... если получилось создать уникальный индекс. ;)

Затем же, зачем и обычно — maintenance.
Но глобальные индексы существенно мешают этому, это да (но зато остальное-то разделится, теоретически).

Ну я имел в виду использование партицирования и postgres_fdw для построения шардированного кластера. FDW не предполагает наличие связей между шардами, толи между координатором и шардами. А без этого нельзя сделать shuffle join. Вообще FDW  разрабатывался как механизм доступа к  различным базам, поэтому его сделали максимально универсальным. А всё что универсальное, обычно не слишком эффективное. У FDW проблемы со статистикой, с параллельным выполнением, с частичным вычислением агрегатов... Он добавляет достаточно большой оверхед (около трёх раз).