Re: Dropping partial index support - Dont! - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Dropping partial index support - Dont!
Date
Msg-id 35D46148.B75606A8@trust.ee
Whole thread Raw
List pgsql-hackers
> Date: Wed, 12 Aug 1998 13:11:53 -0500
> From: "Jackson, DeJuan" <djackson@cpsgroup.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

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: int8 type -- call for porting results!
Next
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Problem with parser