From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Юрий Соколов <funny(dot)falcon(at)gmail(dot)com>, Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Small improvement to compactify_tuples |
Date: | 2017-11-07 22:36:40 |
Message-ID: | 10934.1510094200@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Юрий Соколов | 2017-11-07 22:40:34 | Re: Small improvement to compactify_tuples |
Previous Message | Jacob Champion | 2017-11-07 22:21:56 | Re: [PATCH] Assert that the correct locks are held when calling PageGetLSN() |