Re: Moving _bt_readpage and _bt_checkkeys into a new .c file

Поиск
Список
Период
Сортировка
От Victor Yegorov
Тема Re: Moving _bt_readpage and _bt_checkkeys into a new .c file
Дата
Msg-id CAGnEboj-Of8h8bPh_aF2ZpxBOLMhqJ9L6TA-50Dm9SFJ2aj=+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Moving _bt_readpage and _bt_checkkeys into a new .c file  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Moving _bt_readpage and _bt_checkkeys into a new .c file
Re: Moving _bt_readpage and _bt_checkkeys into a new .c file
Список 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 по дате отправления: