Re: [PATCH] Refactor remaining zero-fill relation extensions to use smgrzeroextend()

Hi,

On Thu, Aug 13, 2026 at 1:50 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> In the CREATE DATABASE path, smgrextend writes just one block with
> zeros (out of N relation blocks only the last one gets written zero),
> so this is already optimized today (which is why with posix_fallocate
> the patch shows no visible benefit here). However, with smgrzeroextend
> and file_extend_method=write_zeros (IOW, on platforms where
> posix_fallocate doesn't exist), this patch increases the disk writes
> (2x) and slows the query (2x).
>
> code exec time (s) disk writes (GB)
> HEAD 59.2 7.3
> patched, posix_fallocate 59.2 7.3
> patched, write_zeros 119.1 14.6
>
> I didn't dive deep into the other paths bulk_write.c and md.c changed
> in this patch, so I'm not sure if they could also hit this problem.

I looked at the other two places. _mdfd_getseg() has the same
optimization as the CREATE DATABASE path (out of N blocks, only the
last one gets zeroed), so the patch has the same problem there.
smgr_bulk_flush() already writes all the gap pages with zeros, so
using smgrzeroextend() there looks good to me.

Using smgrzeroextend() for every zero-fill relation extension, as
mentioned upthread [1], is a good idea. How about we pass only the
last block to smgrzeroextend() and mdzeroextend() in those two places,
something like the attached? This also removes the regression.

code exec time (s) disk writes (GB)
HEAD 58.9 7.3
v1, posix_fallocate 58.9 7.3
v1, write_zeros 118.5 14.6
v2, posix_fallocate 58.9 7.3
v2, write_zeros 58.9 7.3

Barring objections, I will mark the CF entry as Ready for Committer.

[1]
> > The Broader Vision
> > Beyond simple code cleanup, enforcing the responsibility separation of smgrextend() and smgrzeroextend() opens up a clean way to address a long-standing data validation challenge.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com