Re: GiST index implementation - Mailing list pgsql-general

From Gregory Stark
Subject Re: GiST index implementation
Date
Msg-id 87myx8c216.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: GiST index implementation  ("Elena Camossi" <elena.camossi@gmail.com>)
List pgsql-general
"Elena Camossi" <elena.camossi@gmail.com> writes:

> Hi Gregory,
>
> thank you very much for you answer!
>
>>
>> > what is the default implementation for GiST index? B-Tree or R-Tree?
>> > That is, if i execute the following SQL command:
>> >
>> >      CREATE index ON table USING Gist (column)
>> >
>> > what is the type of the index that is actually built?
>>
>> uhm, GIST. GIST is a particular type of index just like btree.
>
>
> according to the documentation (ch 11.2) "GiST indexes are not a single kind
> of index, but rather an infrastructure within wich many different indexing
> strategies can be implemented", and (ch 50.1) "B-Tree, R-Tree and many other
> indexing schemes can be implemented in GiST".

Hm, well that's kind of true from an abstract point of view. But from an
practical point of view it's not really relevant. What you get when you use
GIST indexing Postgres calls a GIST index regardless of what operator class
you use.

Most datatypes only have one GIST operator class. The geometric data types
have a class that is most similar to the old RTree implementation. There is a
GIST operator class for integers which implements an ordered btree style index
-- but you probably would just use a Postgres BTree index if you wanted such
an index.


> I wanted to test the suitability and the efficiency of  R-Tree/GiST for
> query involving standard PostgreSQL temporal column data.
...
> Are these  functionalities all included by default in the standard GiST
> indexing?

The only GIST operator classes which come with the Postgres core are box_ops,
poly_ops, and circle_ops which are the equivalents to the old RTree operator
classes. There are a bunch more in the contrib modules. But I don't see any
related to temporal data.

You might want to look at the seg module and see if it can be altered to work
with temporal data instead. You might also look on Pgfoundry, there might be
something there.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-general by date:

Previous
From: Jorge Godoy
Date:
Subject: Re: Suse RPM's
Next
From: "Gavin M. Roy"
Date:
Subject: Re: What do people like to monitor (or in other words, what might be nice in pgsnmpd)?