Horton

Re: Minmax indexes

Claudio Freire <klaussfreire@gmail.com>

View thread View on postgr.es
From: Claudio Freire <klaussfreire@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Nicolas Barbier <nicolas.barbier@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Andres Freund <andres@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-08-07T14:19:03Z
Lists: pgsql-hackers 
On Thu, Aug 7, 2014 at 11:16 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 7 August 2014 14:53, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
>> <nicolas.barbier@gmail.com> wrote:
>>> 2014-08-06 Claudio Freire <klaussfreire@gmail.com>:
>>>
>>>> So, I like blockfilter a lot. I change my vote to blockfilter ;)
>>>
>>> +1 for blockfilter, because it stresses the fact that the "physical"
>>> arrangement of rows in blocks matters for this index.
>>
>> I don't like that quite as well as summary, but I'd prefer either to
>> the current naming.
>
> Yes, "summary index" isn't good. I'm not sure where the block or the
> filter part comes in though, so -1 to "block filter", not least
> because it doesn't have a good abbreviation (bfin??).

Block filter would refer to the index property that selects blocks,
not tuples, and it does so through a "filter function" (for min-max,
it's a range check, but for other opclasses it could be anything).

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>