) On Tue, Nov 7, 2017 at 1:39 PM, Tom Lane <t...@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-wzmyry7mnjf0gw5wtk3cszh3gqfhhoxvsyuno5pk8cu...@mail.gmail.com -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
