From: | Jingtang Zhang <mrdrivingduck(at)gmail(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
Subject: | Re: Use WALReadFromBuffers in more places |
Date: | 2025-09-20 08:33:20 |
Message-ID: | 92F510DF-321D-4385-B1D8-71781B50777B@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi~
> Thanks for looking at this. Yes, the WAL writers can zero out flushed
> buffers before WALReadFromBuffers gets to them. However,
> WALReadFromBuffers was intentionally designed as an opportunistic
> optimization - it's a "try this first, quickly" approach before
> falling back to reading from WAL files. The no-locks design ensures it
> never gets in the way of backends generating WAL, which is critical
> for overall system performance.
Yes, it is actually an interesting thing, beyond current topic. Since
we are using buffered I/O, even though we cannot read from WAL buffer due
to the opportunistic AdvanceXLInsertBuffer by WAL writer, later WALRead may
still find the page inside OS page cache, with high probability, because the
page has just been written out. So WALRead will be fast, too.
But if we are moving forward to direct I/O some day in the future, the cost
of WALReadFromBuffers and WALRead might be obvious. Maybe the opportunistic
WAL buffer initialization could keep a small ratio of old pages inside WAL
buffer so these pages can still be hit by WALReadFromBuffers.
> I rebased and attached the v3 patch.
The v3 patch LGTM.
—
Regards,
Jingtang
Alibaba Cloud
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-09-20 11:59:02 | Re: Proposal: Conflict log history table for Logical Replication |
Previous Message | Atsushi Torikoshi | 2025-09-20 03:21:39 | Re: RFC: Logging plan of the running query |