Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Alexander Korotkov <a.korotkov@postgrespro.ru>, Thomas Munro <thomas.munro@enterprisedb.com>, Claudio Freire <klaussfreire@gmail.com>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Date: 2018-10-20T04:51:11Z
Lists: pgsql-hackers
On Thu, Oct 18, 2018 at 1:44 PM Andres Freund <andres@anarazel.de> wrote:
> I wonder if it'd make sense to hack up a patch that logs when evicting a
> buffer while already holding another lwlock. That shouldn't be too hard.

I tried this. It looks like we're calling FlushBuffer() with more than
a single LWLock held (not just the single buffer lock) somewhat *less*
with the patch. This is a positive sign for the patch, but also means
that I'm no closer to figuring out what's going on.

I tested a case with a 1GB shared_buffers + a TPC-C database sized at
about 10GB. I didn't want the extra LOG instrumentation to influence
the outcome.

-- 
Peter Geoghegan


Commits

  1. Add "split after new tuple" nbtree optimization.

  2. Add nbtree high key "continuescan" optimization.

  3. Allow amcheck to re-find tuples using new search.

  4. Consider secondary factors during nbtree splits.

  5. Make heap TID a tiebreaker nbtree index column.

  6. Refactor nbtree insertion scankeys.

  7. Redesign the partition dependency mechanism.

  8. Avoid unnecessary palloc overhead in _bt_first(). The temporary