Ticket #1472 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

Disabling SEQSCAN is now a *bad* idea.

Reported by: warmerdam Assigned to: mloskot
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

03/01/07 11:42:52 changed by warmerdam 

Turning over to Mateusz

03/01/07 11:44:31 changed by warmerdam 

note: I'd like this fixed in 1.4 branch as well as trunk.

03/03/07 12:42:22 changed by mloskot 

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 ?

03/03/07 12:57:59 changed by warmerdam 

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.

03/03/07 18:43:56 changed by mloskot 

Fixed in r10869.
Here is detailed changeset:
http://trac.osgeo.org/gdal/changeset/10869

Please, confirm if I should close the bug.

03/05/07 00:02:17 changed by warmerdam 

I suspect this one is also only in trunk...

03/05/07 00:39:07 changed by mloskot 

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

03/05/07 00:40:05 changed by mloskot 

I consider this bug as fixed and closed.