Re: Indexing for geographic objects? - Mailing list pgsql-hackers

On Fri, 8 Dec 2000, Oleg Bartunov wrote:

> On Fri, 8 Dec 2000, The Hermit Hacker wrote:
> 
> > Date: Fri, 8 Dec 2000 12:19:56 -0400 (AST)
> > From: The Hermit Hacker <scrappy@hub.org>
> > To: Tom Lane <tgl@sss.pgh.pa.us>
> > Cc: Oleg Bartunov <oleg@sai.msu.su>, selkovjr@mcs.anl.gov,
> >     'pgsql-hackers ' <pgsql-hackers@postgresql.org>
> > Subject: Re: [HACKERS] Indexing for geographic objects? 
> > 
> > 
> > just a note here ... recently, we had a client with similar problems with
> > using index scan, where turning off seqscan did the trick ... we took his
> > tables, loaded them into a v7.1beta1 server and it correctly comes up with
> > the index scan ...
> > 
> > Oleg, have you tried this with v7.1 yet?  
> 
> Not yet. Just a plain 7.0.3 release. Will play with 7.1beta.
> But we're working in real life and need things to work in production :-)

Okay, then I believe that what you are experience wiht v7.0.3 is already
fixed in v7.1beta, based on similar results I got with some queries and
then tested uver v7.1 ...
> 
>     regards,
>         Oleg
> 
> > 
> > On Fri, 8 Dec 2000, 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.  Note the discrepancy between the estimated
> > > row count and the actual (I assume the "found 18 docs" is the true
> > > number of rows output by the query).  With an estimated row count even
> > > half that (ie, merely two orders of magnitude away from reality ;-))
> > > the thing would've correctly chosen the index scan over sequential.
> > > 
> > > 5000 looks like a suspiciously round number ... how many rows are in
> > > the table?  Have you done a vacuum analyze on it?
> > > 
> > >             regards, tom lane
> > > 
> > 
> > Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> > Systems Administrator @ hub.org 
> > primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> > 
> 
> _____________________________________________________________
> 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
> 
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org