Re: Eagerly evict bulkwrite strategy ring
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>
Date: 2025-09-09T17:36:42Z
Lists: pgsql-hackers
Attachments
- v3-0002-Split-FlushBuffer-into-two-parts.patch (text/x-patch) patch v3-0002
- v3-0003-Eagerly-flush-bulkwrite-strategy-ring.patch (text/x-patch) patch v3-0003
- v3-0001-Refactor-goto-into-for-loop-in-GetVictimBuffer.patch (text/x-patch) patch v3-0001
On Mon, Aug 25, 2025 at 3:03 PM Melanie Plageman <melanieplageman@gmail.com> wrote: > > I just finished a draft of a patch set to do write combining for COPY > FROM using this same heuristic as this patch for deciding to eagerly > flush but then combining multiple buffers into a single IO. That has > larger performance gains, so one could argue to wait to do that. Attached v3 uses the same code structure as in the checkpointer write combining thread [1]. I need the refactoring of FlushBuffer() now included in this set to do the write combining in checkpointer. Upon testing, I did notice that write combining seemed to have little effect on COPY FROM beyond what eagerly flushing the buffers in the ring has. The bottleneck is WAL IO and CPU. While we will need the COPY FROM write combining to use direct IO, perhaps it is not worth committing it just yet. For now, this thread remains limited to eagerly flushing buffers in the BAS_BULKWRITE strategy ring. - Melanie [1] https://www.postgresql.org/message-id/flat/CAAKRu_bcWRvRwZUop_d9vzF9nHAiT%2B-uPzkJ%3DS3ShZ1GqeAYOw%40mail.gmail.com