Re: Logical replication prefetch - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Logical replication prefetch
Date
Msg-id a6978600-ca72-4cb8-82bc-77d292c54f30@garret.ru
Whole thread Raw
In response to Re: Logical replication prefetch  (Konstantin Knizhnik <knizhnik@garret.ru>)
List pgsql-hackers
Completely rewritten version of prefetch patch.
Now prefetch workers do not try to apply LR application and then 
rollback transaction.
They just perform indexes lookup and so prefetch index and referenced 
heap pages.
So no any hacks are needed to prevent lock conflicts and WAL logging.

Performance results are the following (test scenario was explained in 
previous message as well as used schell scripts):

update:
    prefetch (2):           5:20
    prefetch (4):           3:20
    prefetch (8):           2:05
    no prefetch:           8:30

insert:
    pk (4) prefetch:      9:55
    pk+sk(4) prefetch: 5:20
    pk+sk(8) prefetch: 3:08
    no prefetch:           9:20

The number in parentheses specifies number of prefetch workers.
For example to spawn 8 prefetch workers I used the following settings in 
postgresql.conf.replica:

prefetch_replica_identity_only=off
max_worker_processes=16
max_logical_replication_workers=16
max_parallel_apply_workers_per_subscription=8
max_parallel_prefetch_workers_per_subscription=8
port=54322


Also I run continuous test with long (3 hours) updates workload on 
publisher with logical replication to subscriber.
And with 8 prefetch workers replica is able to caught up with primary 
where 10 backends are performing update!
After the end of this updates replica was at the same state as primary 
while without prefetch it proceed only 1/2 of
generated WAL and it takes another 5:30  hours to catch up.




Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Fixing memory leaks in postgres_fdw
Next
From: Bruce Momjian
Date:
Subject: Re: vacuumdb changes for stats import/export