Horton

Re: Minmax indexes

Heikki Linnakangas <hlinnakangas@vmware.com>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Alvaro Herrera <alvherre@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-10T10:20:09Z
Lists: pgsql-hackers 
On 08/10/2014 12:22 PM, Simon Riggs wrote:
> On 8 August 2014 16:03, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
>
>> 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.
>
> What happens if the transaction that does this aborts? Surely that
> means the new value is itself garbage? What cleans up that?

It's no different from Alvaro's patch. The updated MMTuple covers the 
aborted value, but that's OK from a correctnes point of view.

- Heikki

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>