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)

Fri, 2 Apr 2004 16:17:35 +0200 (MET DST)
ohp@pyrenet.fr
GiST future
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


Fri, 02 Apr 2004 09:21:12 -0800
Joe Conway <mail@joeconway.com>
Re: GiST future
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

Fri, 2 Apr 2004 23:33:26 +0400 (MSD)
Oleg Bartunov <oleg@sai.msu.su>
Re: GiST future
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

Fri, 02 Apr 2004 14:40:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: GiST future 