Opened 17 years ago
Last modified 17 years ago
#1472 closed defect (fixed)
Disabling SEQSCAN is now a *bad* idea.
Reported by: | warmerdam | Owned by: | Mateusz Łoskot |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | OGR_SF | Version: | 1.4.0 |
Severity: | major | Keywords: | |
Cc: |
Description
Found it. There's a bug in OGR, which dates back to 2001, when it wasn't a bug, it was a feature. hResult = PQexec(hPGConn, "SET ENABLE_SEQSCAN = OFF"); Frank us turning off sequence scanning as part of his query setup. This is fine if you are only pulling a few features from the table, but if you are pulling *all* the features, it is brutally inefficient. In the new "Modern Era" (since PostGIS 0.8, really) PostGIS is correctly integrated into the query planner, so PostgreSQL will use the indexes when "needed" and not otherwise. Back when Frank wrote this, PostgreSQL would ignore the spatial indexes unless you forced it not to, which was desirable most of the time, so he forced it to use the indexes. Paul
Change History (8)
comment:3 by , 17 years ago
As I understand, the plan of sequential scan should be disabled. Is this a good idea to check PostGIS version and disable it only for versions prior 0.8 ?
comment:4 by , 17 years ago
I think generally disabling it would be fine, but if you want to apply an appropriate version check that would be ok too. I believe the driver already captures the postgis version on connection.
comment:5 by , 17 years ago
Fixed in r10869. Here is detailed changeset: http://trac.osgeo.org/gdal/changeset/10869 Please, confirm if I should close the bug.
comment:7 by , 17 years ago
Frank, Yes, you're right I didn't submitted it to 1.4. Now it's already there: http://trac.osgeo.org/gdal/changeset/10875
Note:
See TracTickets
for help on using tickets.