GiST future
Hi every one.
I've played a bit with contrib/intarray and very much liked being able to
index a whole array.
Now I wonder why 7.4 array queries using SOME/ANY/ALL don't make use of
this king of indexes.
Is there any plan to integrate Oleg's job into the core as GiST indexes
were?
it would be nice to generalize things like
SELECT col1 from table where col2 contains (select col3 from table2 where
...) and use those indexes.
Or did I miss something in the docs?
What does core team think?
Best regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
ohp@pyrenet.fr wrote:
Now I wonder why 7.4 array queries using SOME/ANY/ALL don't make use of
this king of indexes.Is there any plan to integrate Oleg's job into the core as GiST indexes
were?
I hope to get to it someday, but have higher priorities if I can find
some time between now and the 7.5 release. If you want to pitch in and
implement it, by all means, go for it.
Joe
On Fri, 2 Apr 2004, Joe Conway wrote:
ohp@pyrenet.fr wrote:
Now I wonder why 7.4 array queries using SOME/ANY/ALL don't make use of
this king of indexes.Is there any plan to integrate Oleg's job into the core as GiST indexes
were?I hope to get to it someday, but have higher priorities if I can find
some time between now and the 7.5 release. If you want to pitch in and
implement it, by all means, go for it.
current GiST lacks of concurrency and recovery support. It's doable and
there are some plans (me and Teodor) to work on it, but we still have no
time. That means, it's too early to integrate gist based contribs into
core. Also, current GiST interface should be enhanced to be able support
some very interesting data types like digital trees, similarity tree, etc.
Joe
---------------------------(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
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
Joe Conway <mail@joeconway.com> writes:
ohp@pyrenet.fr wrote:
Now I wonder why 7.4 array queries using SOME/ANY/ALL don't make use of
this king of indexes.Is there any plan to integrate Oleg's job into the core as GiST indexes
were?
I hope to get to it someday, but have higher priorities if I can find
some time between now and the 7.5 release. If you want to pitch in and
implement it, by all means, go for it.
GiST indexes aren't really ready for prime time (no WAL logging and poor
concurrent behavior being the main gripes). I'm hesitant to make any of
the core SQL features depend on them until those issues are fixed.
Oleg and Teodor have made noises about doing something about those
problems, but I'm not sure it's at the top of their to-do lists ...
regards, tom lane