Re: Vectored I/O in bulk_write.c - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Vectored I/O in bulk_write.c
Date
Msg-id 20240316191014.yygrmwymspqogxil@alap3.anarazel.de
Whole thread Raw
In response to Re: Vectored I/O in bulk_write.c  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Vectored I/O in bulk_write.c
List pgsql-hackers
Hi,

On 2024-03-16 12:27:15 +1300, Thomas Munro wrote:
> I canvassed Andres off-list since smgrzeroextend() is his invention,
> and he wondered if it was a good idea to blur the distinction between
> the different zero-extension strategies like that.  Good question.  My
> take is that it's fine:
> 
> mdzeroextend() already uses fallocate() only for nblocks > 8, but
> otherwise writes out zeroes, because that was seen to interact better
> with file system heuristics on common systems.  That preserves current
> behaviour for callers of plain-old sgmrextend(), which becomes a
> wrapper for smgrwrite(..., 1, _ZERO | _EXTEND).  If some hypothetical
> future caller wants to be able to call smgrwritev(..., NULL, 9 blocks,
> _ZERO | _EXTEND) directly without triggering the fallocate() strategy
> for some well researched reason, we could add a new flag to say so, ie
> adjust that gating.
> 
> In other words, we have already blurred the semantics.  To me, it
> seems nicer to have a single high level interface for the same logical
> operation, and flags to select strategies more explicitly if that is
> eventually necessary.

I don't think zeroextend on the one hand and and on the other hand a normal
write or extend are really the same operation. In the former case the content
is hard-coded in the latter it's caller provided. Sure, we can deal with that
by special-casing NULL content - but at that point, what's the benefit of
combinding the two operations?  I'm not dead-set against this, just not really
convinced that it's a good idea to combine the operations.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Q: Escapes in jsonpath Idents
Next
From: Andres Freund
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring