[QGIS-trac] [Quantum GIS] #1175: POSTGIS cursor performance

Quantum GIS qgis at qgis.org
Tue Jul 22 18:18:54 EDT 2008


#1175: POSTGIS cursor performance
-----------------------------------------------+----------------------------
   Reporter:  jpalmer                          |              Owner:  jef          
       Type:  enhancement                      |             Status:  new          
   Priority:  minor: annoyance or enhancement  |          Milestone:  Version 1.0.0
  Component:  Data Provider                    |            Version:  0.11.0       
   Keywords:  POSTGIS performance              |   Platform_version:               
   Platform:  All                              |           Must_fix:  Yes          
Status_info:  0                                |  
-----------------------------------------------+----------------------------
 One of the great features that has returned to QGIS is incremental
 rendering of layers and the ability to cancel this rendering. This is
 particularly useful when dealing with large POSTGIS vector layers (i.e.
 millions of features).

 However in the latest version of QGIS I have noticed that there is a large
 delay before features are returned from the POSTGIS provider after each
 viewport change. I think I've tracked this down to way cursors are
 declared for the selection of rows from the database.  Currently in 0.11
 the "with hold" cursor functionality is used. Looking at the postgres
 documentation this means that the backend executes the whole query before
 allowing any rows to be fetched from the cursor. I've noticed that the
 full execution of large layers (or layers with large geometries) in
 POSTGIS can take quite a long time under certain circumstances. These
 circumstances tend to be due to the:
 •       conversion of lots of complex geometries to WKB (i.e. asbinary)
 •       spatial windowing of a layer if the backend planner decides not to
 use the available spatial index.

 I’ve run a few postgres backend tests with cursors using "without hold"
 functionality and declaring a cursor and fetching features in batches of
 10000 is very quick on my system. The only problem with using this
 functionality is that the cursor must be used within a transaction. See
 [http://www.postgresql.org/docs/8.3/interactive/sql-declare.html]. I have
 not looked at the POSTGIS provider code, so there may be implications to
 using this method.


 QGIS version: 0.11 WinXP SP2
 Postgresql version: PostgreSQL 8.1.2 on i686-pc-linux-gnu
 POSTGIS version: POSTGIS="1.1.2" GEOS="2.2.1-CAPI-1.0.1" PROJ="Rel. 4.4.9,
 29 Oct 2004" USE_STATS

-- 
Ticket URL: <http://trac.osgeo.org/qgis/ticket/1175>
Quantum GIS <http://qgis.org>
Quantum GIS is an Open Source GIS viewer/editor supporting OGR, PostGIS, and GRASS formats


More information about the QGIS-trac mailing list