Re: Minmax indexes

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minmax indexes
Date: 2013-09-26 17:39:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas escribió:
> On Wed, Sep 25, 2013 at 4:34 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
> > Here's an updated version of this patch, with fixes to all the bugs
> > reported so far. Thanks to Thom Brown, Jaime Casanova, Erik Rijkers and
> > Amit Kapila for the reports.
> I'm not very happy with the use of a separate relation fork for
> storing this data.

I understand this opinion, as I considered it myself while developing
it. Also, GIN already does things this way. Perhaps I should just bite
the bullet and do this.

> Using an existing fork number rather than creating
> a new one avoids some of them (like, the fact that we loop over all
> known fork numbers in various places, and adding another one will add
> latency in all of those places, particularly when there is a system
> call in the loop) but not all of them (like, what happens if the index
> is unlogged? we have provisions to reset the main fork but any others
> are just removed; is that OK?), and it also creates some new ones
> (like, files having misleading names).

All good points.

Index scans will normally access the revmap in sequential fashion; it
would be enough to chain revmap pages, keeping a single block number in
the metapage pointing to the first one, and subsequent ones are accessed
from a "next" block number in each page. However, heap insertion might
need to access a random revmap page, and this would be too slow. I
think it would be enough to keep an array of block numbers in the
index's metapage; the metapage would be share locked on every scan and
insert, but that's not a big deal because exclusive lock would only be
needed on the metapage to extend the revmap, which would be a very
infrequent operation.

As this will require some rework to this code, I think it's fair to mark
this as returned with feedback for the time being. I will return with
an updated version soon, fixing the relation fork issue as well as the
locking and visibility bugs reported by Erik.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-09-26 17:40:43 Re: Minmax indexes
Previous Message Ivan Lezhnjov IV 2013-09-26 17:15:25 Re: backup.sgml-cmd-v003.patch