| From: | Victor Yegorov <vyegorov(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Moving _bt_readpage and _bt_checkkeys into a new .c file |
| Date: | 2025-12-08 09:13:13 |
| Message-ID: | CAGnEboj-Of8h8bPh_aF2ZpxBOLMhqJ9L6TA-50Dm9SFJ2aj=+w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
пн, 8 дек. 2025 г. в 01:31, Peter Geoghegan <pg(at)bowt(dot)ie>:
> On Sat, Dec 6, 2025 at 9:44 PM Peter Geoghegan <pg(at)bowt(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Klika | 2025-12-08 09:13:20 | Re: Adding REPACK [concurrently] |
| Previous Message | Amit Kapila | 2025-12-08 09:08:32 | Re: Proposal: Conflict log history table for Logical Replication |