Re: Small improvement to compactify_tuples
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, Claudio Freire <klaussfreire@gmail.com>, Юрий Соколов <funny.falcon@gmail.com>, Sokolov Yura <funny.falcon@postgrespro.ru>, Alvaro Herrera <alvherre@2ndquadrant.com>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2017-11-07T22:36:40Z
Lists: pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes: > My point is only that it's worth considering that this factor affects > how representative your sympathetic case is. It's not clear how many > PageIndexMultiDelete() calls are from opportunistic calls to > _bt_vacuum_one_page(), how important that subset of calls is, and so > on. Maybe it doesn't matter at all. According to the perf measurements I took earlier, essentially all the compactify_tuple calls in this test case are from PageRepairFragmentation (from heap_page_prune), not PageIndexMultiDelete. I'd be the first to agree that I doubt that test case is really representative. I'd been whacking around Yura's original case to try to get PageRepairFragmentation's runtime up to some measurable fraction of the total, and while I eventually succeeded, I'm not sure that too many real workloads will look like that. However, if we can make it smaller as well as faster, that seems like a win even if it's not a measurable fraction of most workloads. regards, tom lane
Commits
-
Avoid looping through line pointers twice in PageRepairFragmentation().
- a9169f0200fc 11.0 landed
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited
-
Speed up in-memory tuplesorting.
- 337b6f5ecf05 9.2.0 cited