Re: Minmax indexes
Heikki Linnakangas <hlinnakangas@vmware.com>
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>, Simon Riggs
<simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Nicolas Barbier
<nicolas.barbier@gmail.com>, Claudio Freire <klaussfreire@gmail.com>, "Josh
Berkus" <josh@agliodbs.com>, Andres Freund <andres@2ndquadrant.com>, "Pg
Hackers" <pgsql-hackers@postgresql.org>
Date: 2014-08-08T15:03:54Z
Lists: pgsql-hackers
Attachments
- minmax-v14-heikki-2.patch (text/x-diff) patch v14
I couldn't resist starting to hack on this, and implemented the scheme I've been having in mind: 1. MMTuple contains the block number of the heap page (range) that the tuple represents. Vacuum is no longer needed to clean up old tuples; when an index tuples is updated, the old tuple is deleted atomically with the insertion of a new tuple and updating the revmap, so no garbage is left behind. 2. LockTuple is gone. When following the pointer from revmap to MMTuple, the block number is used to check that you land on the right tuple. If not, the search is started over, looking at the revmap again. I'm sure this still needs some cleanup, but here's the patch, based on your v14. Now that I know what this approach looks like, I still like it much better. The insert and update code is somewhat more complicated, because you have to be careful to lock the old page, new page, and revmap page in the right order. But it's not too bad, and it gets rid of all the complexity in vacuum. - Heikki
Commits
-
Refactor per-page logic common to all redo routines to a new function.
- f8f4227976a2 9.5.0 cited
-
Reduce use of heavyweight locking inside hash AM.
- 76837c1507cb 9.3.0 cited
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited
-
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
- 9e2a87b62db8 7.1.1 cited