Hi, On Thu, Aug 13, 2026 at 1:50 PM Bharath Rupireddy <[email protected]> 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
v2-0001-Use-smgrzeroextend-in-a-few-more-places.patch
Description: Binary data
