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

Andrei Lepikhov <a.lepikhov@postgrespro.ru>

From: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
To: Peter Geoghegan <pg@bowt.ie>
Cc: 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-11-02T10:06:32Z
Lists: pgsql-hackers
I do the code review.
Now, it is first patch - v6-0001... dedicated to a logical duplicates 
ordering.

Documentation is full and clear. All non-trivial logic is commented 
accurately.

Patch applies cleanly on top of current master. Regression tests passed 
and my "Retail Indextuple deletion" use cases works without mistakes.
But I have two comments on the code.
New BTScanInsert structure reduces parameters list of many functions and 
look fine. But it contains some optimization part ('restorebinsrch' 
field et al.). It is used very locally in the code - 
_bt_findinsertloc()->_bt_binsrch() routines calling. May be you localize 
this logic into separate struct, which will passed to _bt_binsrch() as 
pointer. Another routines may pass NULL value to this routine. It is may 
simplify usability of the struct.

Due to the optimization the _bt_binsrch() size has grown twice. May be 
you move this to some service routine?


-- 
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company


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