Re: Moving _bt_readpage and _bt_checkkeys into a new .c file - Mailing list pgsql-hackers

From Victor Yegorov
Subject Re: Moving _bt_readpage and _bt_checkkeys into a new .c file
Date
Msg-id CAGnEboj-Of8h8bPh_aF2ZpxBOLMhqJ9L6TA-50Dm9SFJ2aj=+w@mail.gmail.com
Whole thread Raw
In response to Re: Moving _bt_readpage and _bt_checkkeys into a new .c file  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
пн, 8 дек. 2025 г. в 01:31, Peter Geoghegan <pg@bowt.ie>:
On Sat, Dec 6, 2025 at 9:44 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Since this ignore_killed_tuples change is also very simple, and also
> seems like an easy win, I think that it can be committed as part of
> the second patch. Without it needing to wait for too much more
> performance validation.

My plan is to commit the entire patch series (with a modified second
patch that includes the ignore_killed_tuples change) in the next
couple of days.

As far as I can determine through performance validation that tested a
variety of different scan types (simple point lookups, range scans,
and a variety of different SAOP scan patterns), the patch series is an
unambiguous win. It appears to be slightly faster even in
unsympathetic cases, such as standard pgbench SELECT.

Even without the performance increase, I think this a valuable code reorganization, worth committing.

I've compiled and run test (check and installcheck) with all 3 patches, did a small standard pgbench run:
pgbench -s 100 -i
pgbench -P 60 -T 300

Results:
master: 569 TPS
patched: 590 TPS +3.7%

LGTM.

--
Victor Yegorov

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: David Klika
Date:
Subject: Re: Adding REPACK [concurrently]