[postgis-users] Slow performance when selecting a geometry column

[David Robison]

I am having an issue with a postgis database with the time it takes to query the geometry column. The query selects 8000 records. The time to retrieve the records when not returning the geometry column is about 100ms. However, the time for the same query when requesting the geometry column takes about 9 seconds.  Any thoughts on how I can improve the performance reading the geometry column from a postgis database? I am using PostgreSQL 9.4 and Postgis 22.1.

Thanks, David

 

David Robison

Principal System Engineer

O. +1 757 546 3401

M. +1 757 286 0022

david....@q-free.com

www.q-free.com/openroads

Q-Free Open Roads

103 Watson Road

Chesapeake VA 23320

---

This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. If you are not the intended recipient, please delete this email immediately.

 

 

[Paul Ramsey]

SELECT Sum(ST_NPoints(geom)) FROM thetable;

_______________________________________________
postgis-users mailing list
postgi...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

[David Robison]

So there is a total of over 560,000 points in the 8000 records returned. I would have assumed that it was simply returning the contents of the geometry column and that the number of points (albeit they take up space) would not affect the select time. Is PostGIS doing something with the geometries as it is fetching them from the DB other than just returning them? Thanks, David

[Nordgren, Bryce L -FS]

What kind of network separates client and server? Conservatively assuming that each point is only two 64-bit binary floats, your 560000 points equals 9MB of additional payload.

 

If you did something like “ST_AsText(geom)”, the additional payload is much, MUCH larger.

 

I’d also be interested to know if there’s some kind of data manipulation/packing/compression going on between client and server.

 

Bryce

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

[David Robison]

Actually the timing test was done on the same machine using PGAdmin-III. What is interesting is that if I return the geometry using something like ST_Simplify(the_geom, 0.1, false) then it returns in just a few hundred milliseconds.

David

[Paul Ramsey]

Aah! PgAdminIII. Watch your CPU meter and see how busy PgAdmin is vs PostgreSQL. See how long this runs in:

SELECT ST_Area(geom) FROM mytable;

Still has to rip every geometry off disk, and has to do a *calculation* on it, before returning the result to the client.

P

[Rémi Cura]

Hey

pgadmin takes a long time to __display__ the result of any query.

If you want a somehow better timing,

user EXPLAIN ANALYSE, that is Maj+F7.

It will perform all the real computing, plus some time for measure, but no time for output.

Cheers,