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: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to