Re: WIP: store additional info in GIN index

Alexander Korotkov escribió:
> On Tue, Dec 4, 2012 at 9:34 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> > On Sun, Nov 18, 2012 at 4:54 PM, Alexander Korotkov
> > <aekorotkov(at)gmail(dot)com> wrote:
> > > Patch completely changes storage in posting lists and leaf pages of
> > posting
> > > trees. It uses varbyte encoding for BlockNumber and OffsetNumber.
> > > BlockNumber are stored incremental in page. Additionally one bit of
> > > OffsetNumber is reserved for additional information NULL flag. To be
> > able to
> > > find position in leaf data page quickly patch introduces small index in
> > the
> > > end of page.
> >
> > This sounds like it means that this would break pg_upgrade, about
> > which I'm not too keen. Ideally, we'd like to have a situation where
> > new indexes have additional capabilities, but old indexes are still
> > usable for things that they could do before. I am not sure whether
> > that's a realistic goal.
>
> This means to have two versions of code which deals with posting trees and
> lists. For me it seems unlikely we have resources for maintenance of this.

Witness how GIN has gone with unfixed bugs for months, even though
patches to fix them have been posted. We don't have the manpower to
maintain even *one* such implementation, let alone two.

Maybe we can mark GIN indexes as invalid after pg_upgrade somehow, so
that they require reindex in the new cluster before they can be used for
queries or index updates.

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