Re: Minmax indexes

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, 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-14T23:02:46Z
Lists: pgsql-hackers

Attachments

Alvaro Herrera wrote:
> Heikki Linnakangas wrote:

> > 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.
> 
> It seems there is some issue here, because pageinspect tells me the
> index is not growing properly for some reason.  minmax_revmap_data gives
> me this array of TIDs after a bunch of insert/vacuum/delete/ etc:

I fixed this issue, and did a lot more rework and bugfixing.  Here's
v15, based on v14-heikki2.

I think remaining issues are mostly minimal (pageinspect should output
block number alongside each tuple, now that we have it, for example.)

I haven't tested the new xlog records yet.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Refactor per-page logic common to all redo routines to a new function.

  2. Reduce use of heavyweight locking inside hash AM.

  3. Scan the buffer pool just once, not once per fork, during relation drop.

  4. Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>