а индексы под каждую партицию так же ручками по новой прописывать?)

Ну так "куда не надо" — это же в "основную" таблицу, где (в норме, что там "напилил" тот, кто делал вашу схему, я не знаю, конечно) ничего не должно быть?
Если так, можно же просто сделать DELETE / INSERT... хотя я не помню, работает ли это с rules (у них там куча неожиданных ограничений). Опять-таки, я бы просто выкинул всё это / заменил на нормальную реализацию, если есть возможность. ;)

> а индексы под каждую партицию так же ручками по новой прописывать?)

В декларативном — нет (достаточно на основной таблице). Разве это не счастье? ;)

> В декларативном — нет

Конечно счастье)) Я задолбался в прошлый раз под 9 партиций прописывать стопку индексов))

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

но ведь в итоге это не замедлит поиск в индексах? хотя если бы замедляло, ты бы не посоветовал, надеюсь

а.. или получается я партицирую всегда по конкретному 1 столбцу, но саму партицию могу партцировать еще глубже по другому свойству.. Типа верхний уровень партицирования currency, а ниже date

Вам придётся создать её заново, да. И выбрать принцип партиционирования (один, конечно, не несколько).
Т.е. Вам нужно разобраться, что там пытались делать этими rules (я не смотрел).

> но ведь в итоге это не замедлит поиск в индексах? хотя если бы замедляло, ты бы не посоветовал, надеюсь

Во-первых, почти наверняка замедлит, если запросы "невыровненные". Т.е. если Вам кажется, что партиционирование — это инструмент для ускорения запросов, Вы заблуждаетесь.
Во-вторых, а сейчас "партиционирования" (и замедления) у Вас нет, как будто? ;)
В-третьих — всё равно бы посоветовал, если данных [очень] много — partitioning облегчает maintenance (vacuum, analyze, создание индексов и т.п.). Т.е. тут, бывает, просто деваться некуда.

Не обязательно по одному — можно и по комбинации, а можно и subpartitions, как в этом примере, да.

> Во-первых, почти наверняка замедлит, если запросы "невыровненные"

как понять?)

> Во-вторых, а сейчас "партиционирования" (и замедления) у Вас нет, как будто? ;)

Неа, разбили транзакции по таблицам, грамотно подобрали индексы и пока не встряла проблема с copy всё работало шустро... почти шустро, запросы где я сразу из множества партиций выдирал данные были немного тяжелее, но всё таки получились хорошими по скорости

Пожалуйста, помогите с синтаксисом json path.
Нужно на нем написать аналог вот такого запроса:

SELECT
  j
FROM
jsonb_array_elements(
    '[
      {"key": "foo"},
      {"other": "bar"},
      {"key":  "baz", "other": "blah"}
    ]'::JSONB
) j
WHERE
  j ? 'key'
LIMIT 1

Вернуть первый элемент массива, у которого есть свойство "key".

Пока пишу такое:
SE

LECT
    jsonb_path_query(
      '[
        {"key": "foo"},
        {"other": "bar"},
        {"key":  "baz", "other": "blah"}
      ]'::JSONB,
      '$[*] ? (@.key == "foo" ) [0]')

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

т.е. беда в том, что 400млн транзакций в главной таблице сжирают очень много времени на фильтрации)

> запросы где я сразу из множества партиций выдирал данные

Вот это и есть "невыровненные" запросы. Т.е. такие, которые затрагивают сразу много partitions.
Да и вообще, планирование запросов замедляется, от этого никуда не деться (т.е. это у Вас и сейчас происходит, "чудес" тут нет).
Т.е. Вы просто никогда не сравнивали с непартиционированной таблицей, правда? ;)

Хотя, конечно, бывают ситуации, когда партиционирование ускоряет запросы — я имел в виду, что это не его основное назначение, и такие ситуации — это, скорее, "повезло!". ;)

так изначально у нас и была непартицированная таблица с кучей непонятностей!) Этот ад и стали разбивать... а еще вакуум оказался выключен

Если проблем с maintenance нет (что уже несколько сомнительно при 400M records), то стоит смотреть на планы запросов и индексацию, а не на partitioning.

ROFL! Нет, правда. Т.е. почти наверняка "а еще вакуум оказался выключен" — это и есть причина "улучшений". ;)

не, запросы отлажены, даже выдергивание из разных партиций я делаю через with под каждый отдельный тип фильтрации, чтобы независимо отработали и потом мержу результаты и финально шлифую выдачу (это реально хорошо себя показало)

Привет. Кто-нибудь знает, почему фильтрация по кириллице идет медленнее чем по латинице?

или корректнее будет сказать - поиск

Я как-то сомневаюсь, что это так, даже судя просто по описанию, извините. ;(
Если бы Вы показали какие-то запросы / планы / индексы на исходной таблице, было бы о чём говорить...
Мне кажется, Вы просто сделали "вывод" по принципу "после этого — значит, вследствие этого".
Т.е. Вам "разбиение" просто заменило vacuum (а если его долго не было, bloat мог быть очень существенным), отсюда все "преимущества".

Хмм... а конкретнее? Можете показать запросы / планы, например?