Tom Lane wrote:
> Oleg Bartunov <oleg@sai.msu.su> writes:
> > We've done some work with GiST indices and found a little problem
> > with optimizer.
>
> > test=# set enable_seqscan = off;
> > SET VARIABLE
> > test=# explain select * from test where s @ '1.05 .. 3.95';
> > NOTICE: QUERY PLAN:
>
> > Index Scan using test_seg_ix on test (cost=0.00..369.42 rows=5000 width=12)
>
> > EXPLAIN
> > % ./bench.pl -d test -b 100 -i
> > total: 1.71 sec; number: 100; for one: 0.017 sec; found 18 docs
>
> I'd venture that the major problem here is bogus estimated selectivities
> for rtree/gist operators.
Yes, the problem is, I didn't have the foggiest idea how to estimate
selectivity, nor I had any stats when I developed the type. Before
7.0, I had some success using selectivity estimators of another
datatype (I think that was int, but I am not sure). In 7.0, most of
those estimators were gone and I have probably chosen the wrong ones
or none at all, just so I could get it to work again. The performance
was good enough for my taste, so I have even forgotten that was an
issue.
I know, I know: 'good enough' is never good. I apoligize.
--Gene