Re: Dropping partial index support - Dont!

From: Hannu Krosing <hannu(at)trust(dot)ee>
To: pgsql-hackers(at)postgresql(dot)org
Cc: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>, Jan Wieck <jwieck(at)debis(dot)com>
Subject: Re: Dropping partial index support - Dont!
Date: 1998-08-14 16:09:44
Message-ID: 35D46148.B75606A8@trust.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Date: Wed, 12 Aug 1998 13:11:53 -0500
> From: "Jackson, DeJuan" <djackson(at)cpsgroup(dot)com>
> Subject: RE: [HACKERS] Re: partial index
>
> > I had suspected that's what they were, but never really was sure. Now
> > the next question, "Should we rip them out?" No one uses them, and
> > they seem to be of very limited usefulness.
> >
> > I am inclinded to keep them, but I am not sure.
> >
> Do we have syntax for their creation and is it in the docs?
> If not I say just take them out, unless someone can think of a use that
> wouldn't be served by normal indexes.

They should be much faster than normal indexes, as well as take much
less room. And in principle they coud avoid the need to archive older
records in another table for performance reasons.

As to the difficulty of making optimiser use them we can go the way
Oracle went in v8.0 - support subtable (or whatever they called them ;)

In principle it is a subset of one table, selected by some condition.

The syntax could be something like this:

create subtable parents on table people where no_of_children > 0;

create index on parents using btree(no_of_children);

this way you do actually create a partial index on people, but you
give the optimiser a strong hint to use this index if you do select on
table parents.

I suspect that the subtable itself is created by making a
partial index or like structure on the where clause.

-----------------
Hannu Krosing

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1998-08-14 17:05:36 Problem with parser
Previous Message Thomas G. Lockhart 1998-08-14 15:46:53 int8 type -- call for porting results!