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

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Peipei YIN <yinpeipei0426(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Refactor remaining zero-fill relation extensions to use smgrzeroextend()
Date: 2026-09-25 05:07:25
Message-ID: CAGRkXqT=dSXm9VAy2v2m2LT2uk2T+Vk97J_NZk7PZetaaevihQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I reviewed v2. It fixes both regressions I raised on v1. With one
block, mdzeroextend() takes the same FileZero() path as the old
mdextend() call, so nothing changes at runtime there.

One request. smgrzeroextend(..., nblocks - 1, 1, ...) looks like a bug
unless you know why, and changing it to (0, nblocks) brings the 2x
regression back. Please add a one line comment in bufmgr.c and md.c
saying only the last block is written on purpose.

Nit, the "don't set checksum" comment in bulk_write.c no longer
applies, since no page is passed.

Note that v2 does not move toward the zero page detection idea. The
blocks before the last one are still holes, which read as zeros and
never pass through smgrzeroextend(). Making them non-zero means writing
them, which is the 2x cost Bharath measured.

Thanks,
Shihao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-09-25 05:30:39 Re: Fix -Wshadow=local warnings
Previous Message Fujii Masao 2026-09-25 04:57:37 Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18