Re: Indexing for geographic objects?

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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