Много ограничений )

Безусловно, иногда глобальный индекс будет медленее чем локальный (если в фильтре присутствует ключ по которому секционирована таблица), но будут ситуации когда он будет быстрее - будет проще перебрать его, чем перебрать сотню локальных.

Представьте, что поверх postgres строят OLAP кубы - разрезы данных будут самые разные, и фильтры могут попадать на одну секцию, а могут перебирать их все. Тут будет смысл в наличии двух одинаковый индексов - локального и глобального - да изменение данных будет крайне медленным, но обычно на таких системах ETL процессы не требуют высокой отзывчивости

Понятно, спасибо!
Но это же всё же не про партционирование, а про шардирование...

ну с локальным партицированием ситуация гораздо лучше - там почти всё доделали

Да, и осталось ещё его нормально переделать, а то иногда возникает ощущение, что в некоторых местах его в планировщик забивали кувалдой. ;)
И вообще, как-то работа над партиционированием замедлилась, такое ощущение...

Вот это "изменение данных будет крайне медленным" может быть настолько плохо, что и партиционировать не захочется.
Если я правильно помню, сейчас ситуация такая, что (почти?) никому из hackers вообще не хочется что-то делать в этом направлении...

Раньше основным драйвером в этом направлении было EDB. Сейчас они как-то охладели к этой затее. Им сейчас похоже не до того.

Сейчас у нас в ПгПро Анастасия  работает над  автоматическим созданием партиций

Господа, добрый вечер! Хочу развернуть на локалке дамп с серверной бд. Делаю дамп, выкачиваю на локалку и пытаюсь импортировать в бд. Ругается на отсутствие template1. Вот полный лог моих действий: https://gist.github.com/clockdev/15fbff0dcc5330a2cf822500ca0ed789

Подскажите пожалуйста, не могу нагуглить какого-то адекватного решения. Локалка – macOS с Postgres.app

Всем привет, подскажите плз по пгадмину

если я у себя в ноуте сменил диск, и работаю не на винде (он там был установлен), а на убунте

могу ли я перенести данные пгадмина к себе на рабочую ос на другом диске?

в инете не нагуглил

Всем спасибо, решил

Всем привет! Подскажите в чем разница между IN и ANY? Насколько я понял это почти одно и тоже. Может какой то из них быстрее?

https://stackoverflow.com/questions/34627026/in-vs-any-operator-in-postgresql
tl;dr в синтаксисе

В массив строк?

в таблицу,
при условии, что такая строка уже есть в какой-либо записи

Не существенно.
Думай лучше о доменной целостности данных

Я к тому, что ты запустил медведя на пасеку, сделал массив в реляционной СУБД - теперь будешь страдать, сам виноват.

Сделай проверку триггерами или плюнь вообще на эту проверку. Проверяй в приложении как-то

ну а все-таки, какой порядок падения перформанса?
я когда-то мерил что-то подобное, но тогда сервер у меня назывался Пентиум 133 :)
так что данные не актуальны

ну монга вполне такое прожевывала, и тут хотелось бюы по минимуму менять схему.

и вечный русский вопрос "кто виноват" - вообще не кактит здесь.
есть только вопрос как лучше сделать в имеющихся условиях

проверку триггерами, как именно предалгаешь?
напомню, что у нас read commited

Нет разницы, если any вводится через =.

А так ANY по функционалу гораздо шире IN.

Но = ANY профессионалы не применяют, а ANY с любыми другими вводными операциями очень редко имеют смысл, и могут быть заменены на что-то другое, как правило, коррелированный подзапрос, и в итоге в практике программирования ANY не используется, его обсуждают только в учебниках по SQL