Opened 17 years ago

Closed 14 years ago

#581 closed enhancement (fixed)

POSTGIS Layer feature count methodology

Reported by: jpalmer Owned by: jef
Priority: minor: annoyance Milestone: Version 1.0.3
Component: Data Provider Version: Trunk
Keywords: postgis count table Cc: jef
Must Fix for Release: No Platform: All
Platform Version: Awaiting user input: no

Description

Currently in the win32 0.8 release (and any release that does not define the POSTGRESQL_THREADS macro) the POSTGIS data provider always does a full table count select. This is very annoying to the user who might have to wait some time when added a new layer that has millions of features.

A better solution is to use the pg_catalog information when the layer is first added then complete a full table count if required for later requirement. The layer properties could then just show that the count was estimated.

I believe this is the intended scenario if POSTGRESQL_THREADS is defined. So maybe the win32 version just needs to be compiled with thread support.

Also noted is that in the "thread section" current query is:

"select reltuples from pg_catalog.pg_class where relname = '" +

tableName + "'";

This should be changed to include the use of schemas:

QString sql = ""

"SELECT cls.reltuples " "FROM pg_catalog.pg_class cls, " " pg_catalog.pg_namespace nsp " "WHERE cls.relname = '" + mTableName + "'" "AND cls.relnamespace = nsp.oid " "AND nsp.nspname = '" + mSchemaName + "'";

Change History (9)

comment:1 by g_j_m, 17 years ago

Unfortunately, many parts of qgis require the feature count to be accurate at all times, and if not causes subtle errors in displaying feature and attribute data. For these reasons the POSTGRESQL_THREADS code has not been used since soon after it was written.

comment:2 by anonymous, 17 years ago

I think from a user’s point of view it is very annoying having to wait a long period just to load a layer - especially if it is just to view the feature and info features.

I believe the user would be ok with layer initially loading the layer with an estimated count and then having an immediate thread spawned off in the background to complete the full count.

Correct me if I'm wrong but aren’t feature retrieved independent of the layer count i.e. "getNextFeature". So the count should not apply in drawing and feature info functions.

Maybe these subtle areas of the application (i.e feature attribute table) could be explained (locked down?) to the user while the full count is carried out. I know this means more complication to the application and more work for the developers – but it would be very useful to users of large POSTGIS layers 

comment:3 by msieczka, 16 years ago

Awaiting user input: set

How does the issue look in QGIS 0.11? You can obtain it's Windows installer preview at:

http://gigamaildownload.rossoalice.alice.it/download/download.aspx?AttachmentID=2716cab8-980a-45c8-9e9c-8ff538f973e2&MessageID=4602d09e-2a74-48e1-a167-644cb19b13fb

comment:4 by jpalmer, 16 years ago

I just tested the latest QGIS 0.11 win32 preview. The count method is still as reported. i.e "select count(*) from table".

comment:5 by msieczka, 16 years ago

Awaiting user input: unset
Cc: jef added

Jürgen,

CCing you a PostGIS expert.

comment:6 by jef, 16 years ago

Owner: changed from nobody to jef

comment:7 by jef, 15 years ago

Type: defectenhancement

comment:8 by jef, 15 years ago

Platform: WindowsAll

comment:9 by jef, 14 years ago

Resolution: fixed
Status: newclosed

fixed in r13044. See also #2460.

Note: See TracTickets for help on using tickets.