В общем, это всё т.н. abort-early plan. См. https://www.postgresql.org/message-id/541A2335.3060100@agliodbs.com
Вот что с этим делать — это интересный вопрос (потому что сам используемый принцип оценки — это псевдоматематическое шаманство).
Т.е. эту дурь в плане оценок Вы из планировщика не выбьете. ;)
Поэтому можно как-то сделать так, чтобы либо index scan IX_Message_Subject ему казался подороже, либо bitmap index scan trgm_idx_message_subject подешевле.
А у Вас PostgreSQL настроен под железо/нагрузку, вообще? Может, если заняться tuning, удастся убить сразу двух зайцев (но можно и новых найти, не без этого)? ;)

Спасибо. Это AWS RDS. Я с ним мало что могу сделать. Хотя в принципе железо однотипное. И если есть какие-то доступные  параметры, которые стоит подтюнить - было бы полезно.

Так это и не PostgreSQL (а fork), если я правильно помню... Я просто не знаю, что там вообще можно настраивать. :(

Да вроде настоящий. Почти). Нет полного админа со всеми вытекающими, но многие глобальные настройки можно сделать из консоли амазона

Ну так всё равно с его tuning нужно отдельно разбираться (искать где-то), мне кажется.

Вероятно. Я планировал косты для оптимизатора подтюнить, чтоб было ближе к тому, что на железе. Это скорее всего единственное, что можно сделать. Но что-то мне подсказывает, что это не поможет.  Спасибо за консультацию.

🐨 А у меня вакансия есть.
Может, кто из местных обитателей сейчас в поиске.

Ну так об этом и речь, но настраивать нужно всё равно с учётом их специфики.
Может и помочь (к примеру, обычное изменение cpu_tuple_cost может как раз изменить оценки в нужном в этом случае направлении, кажется). Но не факт, да.
Кстати, Вы могли бы конкретно эту посмотреть (что у них там default) / попробовать в сессии.

#DBA #АдминистраторСУБД #PostgreSQL #вакансия #Москва #fulltime #финтех

🙂 В поиске PostgreSQL DBA (Администратор СУБД Postgres) на стратегический проект финтех компании.
Цель: внедрение и развитие цифровой платформы для банковских гарантий. Цель интересная, амбициозная и является
стратегической.

⚙ Задачи таковы:
-администрирование корпоративных баз данных СУБД PostgreSQL;
-оптимизация производительности запросов;
-мониторинг работоспособности и производительности СУБД PostgreSQL.
-обеспечение высокой доступности СУБД и резервного копирования.

🗄 Ожидаем, что кандидат обладает:
-навыками администрирования СУБД PostgreSQL;
-навыками администрирования Linux;
-понимает принципы кластеризации СУБД PostgreSQL;
-имеет опыт проектирования баз данных.

Желателен навык администрирования ElastiсSearch.

💻 Условия работы:
-кэш 230 gross
-современный офис в шаговой доступности от метро (1 остановка от кольцевой)
-тренинги и конференции за счет компании
-возможность влиять на компанию и ее продукты, поддержка инициатив сотрудников
-экологичный коллектив, классное руководство

🐾 Буду признателен за рекомендации!

📧 Мои контакты:
nikitakarpovmail@gmail.com
tlgrm - @IamINFJ

Всем привет
Есть две таблицы A и B в отношении OneToMany
A: id, state, date
B: amount, userId, aId

В таблице B записей в отношении к одному id из A может быть сколько угодно
Стоит задача по userId просуммировать все записи из B, относящиеся к A по определенной date

Этим запросом я вытаскиваю сумму по каждой записи из A:

SELECT Coalesce(SUM(Coalesce("b"."amount", 0)), 0) :: FLOAT 
         FROM "a"
                left join "b"
                       ON "b"."aId" = "a"."id" 
         WHERE  "b"."userId" = '123'
   AND "a"."date" BETWEEN '...' AND '...'
         GROUP  BY "a"."id»

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

Проще: как просуммировать группу сумм?

убрать GROUP BY, получишь тотал всех b.amount

и left join здесь ни к чему, поскольку фильтрация идет по b.user_id, inner join

Все привет. Стоит ли использовать ltree в PostgreSQL?

SELECT Coalesce(SUM(Coalesce("b"."amount", 0)), 0) :: FLOAT 
         FROM "a"
                left join "b"
                       ON "b"."aId" = "a"."id" 
         WHERE  "b"."userId" = '123'
   AND "a"."date" BETWEEN '...' AND '...'
         GROUP  BY "a"."id»

Coalesce(SUM(Coalesce("b"."amount", 0)), 0) :: FLOAT 

Ну и ужас... Надеюсь, что amount — это, хотя бы, не деньги.

А что это такое ?

Coalesce(SUM(Coalesce("b"."amount", 0)), 0) :: FLOAT 

Как улучшить это место?

Если он подходит к задачам / запросам — почему бы нет?
Но если Вам нужны деревья, я бы начинал с adjacency list + rCTE, и смотрел на что-то другое в том случае, если это не подходит.

Убрать лишние COALESCE и CAST, например.

расширение под новый тип столбца в котором удобно хранить иерархические структуры