Comments 8
PostgreSql не умеет переписывать "x in (select..." <-> "exists (...) "?
умеет, только что проверил — планы генерируются одинаковые
планы
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.
PgPool есть, который это может, но по факту мы не рекомендуем его использовать.
Можете поделиться опытом, почему вы не рекомендуете использовать pgpool
Можете посмотреть ответ Алексея Лесовского https://qna.habr.com/q/49000
Max_standby_streaming_delay – это самый универсальный параметр
А тогда возникает вопрос: а где все это время будут храниться WAL-журналы присылаемые на слейв? Понятно, что слейв их будет у себя складировать, но должен же быть ограничитель количества этих журналов, которые ждут пока запрос «крутится» на слейве.
И где можно подробнее почитать про упомянутые в статье параметры, т.к. в документации о них ничего непонятно?
На сколько я вижу из практики, слейв у себя не складирует, а запрашивает у мастера нужное — мастеру нужно обеспечить достаточную историю wal-логов.
Либо, что гораздо надёжнее, организовать архивирование и доставку wal-логов на слейв (или общее хранилище) сторонним процессом. А слейв научить эти логи доставать по мере необходимости.
Либо, что гораздо надёжнее, организовать архивирование и доставку wal-логов на слейв (или общее хранилище) сторонним процессом. А слейв научить эти логи доставать по мере необходимости.
Sign up to leave a comment.
Борьба с нагрузкой в PostgreSQL, помогает ли репликация в этом. Андрей Сальников (Data Egret)