From: | selkovjr(at)mcs(dot)anl(dot)gov |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, "'pgsql-hackers '" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Indexing for geographic objects? |
Date: | 2000-12-09 03:22:02 |
Message-ID: | 200012090322.VAA01535@selkovjr.xnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Tom Lane wrote:
> Oleg Bartunov <oleg(at)sai(dot)msu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2000-12-09 04:18:13 | Re: Japan pictures |
Previous Message | Bruce Momjian | 2000-12-09 01:40:07 | Japan pictures |
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-12-09 03:40:19 | Re: Re: COPY BINARY file format proposal |
Previous Message | Tom Lane | 2000-12-09 03:17:00 | Re: Re: CRC |