В статье или использовать пг >=11

А кто знает, почему все обычно пишут, что конфиг по умолчанию postgres никуда не годится в продакшен, но разработчики не делают автогенерацию, наподобие pgtune? Есть какой то тайный смысл в этом?

потому что на дефолтном конфиге можно быстрее понять откуда ноги растут

кстати а есть какойнить best practices  по конфигу для разных задач, может на гитхабе ?

нет. только боль и страдание

прискорбно

прочитал  3 раза,но там не о моей ситуации

Господа, подскажите пожалуйста, есть какой-нибудь способ шарить users и rls policy между инстансами?

Или между db

хорошая статья, но там ещё один аспект есть:

они делают CHECK constraint вместо прямолинейного NOT NULL. Если хотим [пере]определить PK, так не сработает.

С 11 можно делать трюк: ALTER .. SET NOT NULL DEFAULT -1 (супербыстро, если версия 11+), а потом батчами обновляем старые строки, постепенно избавляясь от -1.  Именно так PK можно переопределять

Господа? Пошлите хоть в какую-нибудь сторону

какие индексы уже есть?

ALTER TABLE user ADD COLUMN number INTEGER DEFAULT 0;

Раз 11 версия, то про рецепты как быстро добавлять колонку с дефолтом можно не говорить.

Значит, надо локи смотреть

в одном psql запустить ещё раз. В другом — взять вот этот гигантский запрос и проверить, кто кого блочит  https://gitlab.com/-/snippets/1890428

сложно понять вопрос. Хочется БД-юзеров реплицировать между двумя и более мастерами? Тут что-то писать нужно кастомное, исходя из уже используемых инструментов в инфре.

csco_idesind

Indexes:
    "pk_csco_idesind" PRIMARY KEY, btree (gvkey, datadate, indfmt, consol, fyr, popsrc, datafmt, effdate, item)
    "csco_idesind_datadate_idx" btree (datadate) WHERE datadate >= '2010-01-01 00:00:00'::timestamp without time zone AND datadate <= '2020-07-01 00:00:00'::timestamp without time zone
    "csco_idesind_gvkey_idx" btree (gvkey)
Access method: heap

csco_ifndq
Indexes:
   "pk_csco_ifndq" PRIMARY KEY, btree (coifnd_id, effdate, item)
   "csco_ifndq_coifnd_id_idx" btree (coifnd_id)
Access method: heap

а вторая?

Сорри, вижу, что две.

Можно попробовать для начала вот от этого избавиться

Filter: (gvkey = ANY ('{~1600 items}'::integer[]))
                           Rows Removed by Filter: 1536564

добавив gvkey второй колонкой в определение csco_idesind_datadate_idx

ну и напрашивается partitioning

Индекс по gvkey, кстати, отдельный вообще не нужен -- оно уже проиндексировано в PK

можно было бы помеменять 1й и 2й столбец местами в PK и не делать тогда уже csco_idesind_datadate_idx совсем (тем более оно частичное). Т.е. PK нам бы и помогал навигировать по datadate и далее по gvkey.

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