Re: Small improvement to compactify_tuples

)

On Tue, Nov 7, 2017 at 1:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So I think we should seriously consider the attached, but it'd be a
> good idea to benchmark it on a wider variety of platforms and test
> cases.

> create unlogged table test3 (
>          id integer PRIMARY KEY with (fillfactor=85),
>          val text
>      ) WITH (fillfactor=85);

Passing observation:  Unlogged table B-Tree indexes have a much
greater tendency for LP_DEAD setting/kill_prior_tuple() working out
following commit 2ed5b87f9 [1], because unlogged tables were
unaffected by that commit. (I've been meaning to follow up with my
analysis of that regression, actually.)

The same is true of unique indexes vs. non-unique. There are workloads
where the opportunistic LP_DEAD setting performed by
_bt_check_unique() is really important (it calls ItemIdMarkDead()).
Think high contention workloads, like when Postgres is used to
implement a queue table.

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.

[1] https://postgr.es/m/CAH2-WzmYry7MNJf0Gw5wTk3cSZh3gQfHHoXVSYUNO5pk8Cu7AA@mail.gmail.com
-- 
Peter Geoghegan