"Elena Camossi" <elena.camossi@xxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
