Борьба с нагрузкой в PostgreSQL, помогает ли репликация в этом. Андрей Сальников (Data Egret)

[xtender]

PostgreSql не умеет переписывать "x in (select..." <-> "exists (...) "?

[edo1h]

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

планы

                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=257210.05..1431536.67 rows=743400 width=41)
   Workers Planned: 2
   ->  Merge Join  (cost=256210.05..1356196.67 rows=309750 width=41)
         Merge Cond: (chequeline.cheque_id = cheque.id)
         ->  Parallel Index Scan using chequeline__cheque_id_n on chequeline  (cost=0.44..2853638.37 rows=11072229 width=41)
         ->  Sort  (cost=255036.69..255873.68 rows=334797 width=4)
               Sort Key: cheque.id
               ->  Index Scan using cheque__shift_id_chequeuid on cheque  (cost=0.56..221044.16 rows=334797 width=4)
                     Index Cond: ((shift_id >= 1000) AND (shift_id <= 2000))
 JIT:
   Functions: 10
   Options: Inlining true, Optimization true, Expressions true, Deforming true
(12 rows)

postgres=# explain select * from chequeline where exists (select id from cheque where cheque.id=cheque_id and shift_id  between 1000 and 2000);
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=257210.05..1431536.67 rows=743400 width=41)
   Workers Planned: 2
   ->  Merge Join  (cost=256210.05..1356196.67 rows=309750 width=41)
         Merge Cond: (chequeline.cheque_id = cheque.id)
         ->  Parallel Index Scan using chequeline__cheque_id_n on chequeline  (cost=0.44..2853638.37 rows=11072229 width=41)
         ->  Sort  (cost=255036.69..255873.68 rows=334797 width=4)
               Sort Key: cheque.id
               ->  Index Scan using cheque__shift_id_chequeuid on cheque  (cost=0.56..221044.16 rows=334797 width=4)
                     Index Cond: ((shift_id >= 1000) AND (shift_id <= 2000))
 JIT:
   Functions: 10
   Options: Inlining true, Optimization true, Expressions true, Deforming true
(12 rows)

встречал разное поведение, но, вроде бы, только на древних версия postgresql.

[xtender]

Спасибо, собственно, так и думал, что сейчас все ведущие rdbms это умеют, поэтому совет с переписыванием и удивил.

[edo1h]

ну тут и про min/max зря написано, они давно уже прекрасно оптимизируются (при наличии подходящего индекса, конечно).

[bigtrot]

PgPool есть, который это может, но по факту мы не рекомендуем его использовать.

Можете поделиться опытом, почему вы не рекомендуете использовать pgpool

[chemtech]

Можете посмотреть ответ Алексея Лесовского https://qna.habr.com/q/49000

[MadMaxi]

Max_standby_streaming_delay – это самый универсальный параметр

А тогда возникает вопрос: а где все это время будут храниться WAL-журналы присылаемые на слейв? Понятно, что слейв их будет у себя складировать, но должен же быть ограничитель количества этих журналов, которые ждут пока запрос «крутится» на слейве.

И где можно подробнее почитать про упомянутые в статье параметры, т.к. в документации о них ничего непонятно?

[Lelik13a]

На сколько я вижу из практики, слейв у себя не складирует, а запрашивает у мастера нужное — мастеру нужно обеспечить достаточную историю wal-логов.
Либо, что гораздо надёжнее, организовать архивирование и доставку wal-логов на слейв (или общее хранилище) сторонним процессом. А слейв научить эти логи доставать по мере необходимости.