Hi,
On Wed, Sep 24, 2025 at 11:27 AM Jeff Davis <
pgsql@j-davis.com> wrote:
>
> On Wed, 2025-09-24 at 07:26 -0700, Bharath Rupireddy wrote:
> > Right. Reading unflushed WAL buffers for replication was one of the
> > motivations. But, in general, WALReadFromBuffers has more benefits
> > since it lets WAL buffers act as a cache for reads, avoiding the need
> > to re-read WAL from disk for (both physical and logical) replication.
> > For example, it makes the use of direct I/O for WAL more realistic
> > and
> > can provide significant performance benefits [1].
>
> Is it possible to do a POC that shows the potential benefit, or are we
> still too far away?
Thanks for looking into this. I did performance analysis with WAL directo I/O to see how reading from WAL buffers affects walsenders:
https://www.postgresql.org/message-id/CALj2ACV6rS%2B7iZx5%2BoAvyXJaN4AG-djAQeM1mrM%3DYSDkVrUs7g%40mail.gmail.com. Following is from that thread. Please let me know if you have any specific cases in mind. I'm happy to run the same test for logical replication.
It helps WAL DIO; since there's no OS
page cache, using WAL buffers as read cache helps a lot. It is clearly
evident from my experiment with WAL DIO patch [1], see the results [2]
and attached graph. As expected, WAL DIO brings down the TPS, whereas
WAL buffers read i.e. this patch brings it up.[2] Test case is an insert pgbench workload.
clients HEAD | WAL DIO | WAL DIO & WAL BUFFERS READ | WAL BUFFERS READ
1 1404 1070 1424 1375
2 1487 796 1454 1517
4 3064 1743 3011 3019
8 6114 3556 6026 5954
16 11560 7051 12216 12132
32 23181 13079 23449 23561
64 43607 26983 43997 45636
128 80723 45169 81515 81911
256 110925 90185 107332 114046
512 119354 109817 110287 117506
768 112435 105795 106853 111605
1024 107554 105541 105942 109370
2048 88552 79024 80699 90555
4096 61323 54814 58704 61743--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services:
https://aws.amazon.com
