Re: sp-gist porting to postgreSQL - Mailing list pgsql-hackers

From Ramy M. Hassan
Subject Re: sp-gist porting to postgreSQL
Date
Msg-id 200411100703.iAA73jEE012879@arthur.cs.purdue.edu
Whole thread Raw
In response to Re: sp-gist porting to postgreSQL  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: sp-gist porting to postgreSQL  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Oleg,

Thanks for your prompt reply.
Actually, I am able to create a new access method for testing and add an
operator class for the type "integer" using the new access method. Then
created a table with two integer fields, one indexed using the new access
method and the other using a btree index, and everything is ok so far. Even
using EXPLAIN statement for queries show that the indexes are used correctly
as they should.
I am using postgresql version 8.0.0beta3 from CVS.

Thanks
Ramy



-----Original Message-----
From: Oleg Bartunov [mailto:oleg@sai.msu.su] 
Sent: Wednesday, November 10, 2004 12:35 AM
To: Ramy M. Hassan; Pgsql Hackers
Cc: Teodor Sigaev; Walid G. Aref
Subject: Re: sp-gist porting to postgreSQL

Ramy,

glad to hear from you !
AFAIK, posgresql doesnt' supports several indices for the same type.
I think this is a problem of optimizer. Probably other hackers know
better. I forward your message to -hackers mailing list which is a
relevant place for GiST discussion.
    regards,        Oleg


On Tue, 9 Nov 2004, Ramy M. Hassan wrote:

> Dear Oleg and Teodor,
> Thanks for offering help.
> I have a design question for now.
> Currently in the postgresql GiST implementation, I noticed that the way to

> have a GiST based index is to define an operator class for a certain type 
> using GiST index. There is no new index type defined from the point of
view 
> of postgresql ( nothing is added to pg_am ). This means that for a certain

> type there could only be one GiST based index. I mean that there is no way
in 
> the same server to use gist to implement an xtree index and a ytree  for
the 
> same  type even if they index different fields in different relations. is 
> that correct ?
> What about doing it the other way ( I am talking about SP-GiST now ) , by 
> providing the extension writer with an API to use it to instantiate a 
> standalone SP-GiST based index ( for example trie index ) that has a
record 
> in the pg_am relation. In my point of view this would give more
flexibility, 
> and also would not require the extension writer to learn the postgresql
API ( 
> maybe oneday SP-GiST will be ported to another database engine )  he will 
> just need to learn the SP-GiST API which will propably be less amount of 
> study  (and this is what GiST and SP-GiST is all about if I correctly 
> understand ).
> Please let me know your opinions regarding to this.
>
> Thanks
>
> Ramy
>
    Regards,        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83



pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: sp-gist porting to postgreSQL
Next
From: Oleg Bartunov
Date:
Subject: Re: sp-gist porting to postgreSQL