Re: WAL-support for Pluggable Indexes - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WAL-support for Pluggable Indexes
Date
Msg-id 603c8f071002211020i7f896303y1f9455736a3621b0@mail.gmail.com
Whole thread Raw
In response to WAL-support for Pluggable Indexes  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Sun, Feb 21, 2010 at 12:54 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> We've just rejected Knn-gist indexes as "not enough time for 9.0", which
> is a considerable disappointment for many people.
>
> We already have a pluggable index API, but not one that supports
> recoverability.
>
> It is a simple patch to add recoverability to the index API, if we have
> the will to do so.
>
> Let's add this into 9.0 now and let index development flourish without
> the need for integration with core. PostgreSQL will benefit from having
> index types grow alongside it. There will at times be additional changes
> in core to optimise certain index use cases, that can come later. Let's
> allow Postgres to be what it was always intended to be: extensible for
> real world applications.
>
> The must-have list of requirements are:
> * must be possible to test whether rmgrid is set before allowing
> XLogInsert()
> * must allow normal rmgr APIs as well as index AM API
>
> Not looking for the ability to redefine existing rmgrs, just ability to
> add new ones.
>
> I'm looking for agreement to proceed now and some help from those with
> an interest.

I am also disappointed that knngist didn't make it into 9.0, but it
seems somewhat orthogonal to the issue you're raising here.  Knngist
can't exist outside of core because it requires planner support and
changes to the opclass machinery; so even if we did this, it wouldn't
actually benefit the proposed use case.  That doesn't mean this is a
bad idea, of course, just that it doesn't solve that particular
problem.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WAL-support for Pluggable Indexes
Next
From: Tom Lane
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql