[postgis] SET ENABLE_SEQSCAN = OFF

[Dave Blasby]

> I think we are reaching the point where we go back to the [HACKERS] list
> and ask what we can do about this. Fundamentally, this is a problem with
> how the planner scores the likelihood of a query on our GiST index doing
> better with the index than with a sequence scan, and that problem has to
> do with the kind of statistics the planner is gathering on the table.
> There does not seem to have been any thought given to having the planner
> work right on anything except btrees, hence we have to force index scans
> whenever we work with the GiST indexes. Without guidance from the
> experts on HACKERS though, there is nothing we can do ourselves: it's
> pretty deep voodoo.

There are functions that you can set that affect how the planner will
calculate search costs and, hence, whether or not an index is used.  We
may be able to just give a HUGE cost to the CPU time involved in
computing "&&" and it may always optimize by using the GiST index.

> > However, the good news is that I have modified OGR to pass attribute
> > and spatial queries through to PostGIS, and the performance is great
> > when selecting a small area out of a large dataset.
> 
> That's fantastic news!

I second that!

dave

To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/