On Wed, Sep 24, 2025 at 12:32 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.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].
>
> Thanks for looking into this. I did performance analysis with WAL directo I/O to see how reading from WAL buffers
affectswalsenders:
https://www.postgresql.org/message-id/CALj2ACV6rS%2B7iZx5%2BoAvyXJaN4AG-djAQeM1mrM%3DYSDkVrUs7g%40mail.gmail.com.
Followingis from that thread. Please let me know if you have any specific cases in mind. I'm happy to run the same test
forlogical 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
Thank you all for reviewing this. Please find the attached rebased
patch for further review.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
