[mapserver-users] long-running postgres queries initiated by mapserver

[Carlos Ruiz]

Matt,

I suggest to enhance the PostgreSQL performance at first. Each table with 
geometry must have a GiST spatial 

index. When you upload a shape file to PostgreSQL, the shp2pgsql creates this 
index specifying the -I 

parameter.

Have you uploaded your data in this way ?

If the geometry have been modified with PostGIS, you must recompute statistics 
to have the index updated.

Check if you have a spatial index in your table.

Cheers from México


IC Carlos Ruiz



________________________________
From: mattmendick <matt.mendick at pictometry.com>
To: mapserver-users at lists.osgeo.org
Sent: Tue, December 21, 2010 8:48:19 AM
Subject: [mapserver-users] long-running postgres queries initiated by mapserver


Hi All-

I'm running mapserver 5.6.3 under centos 5.4, using fastcgi. I'm using
postgres as the data storage container, and mapserver is primarily serving
WFS requests.  Sometimes, people do WFS queries that take a very long time
(searching for "virginia" on a nation-wide layer) and eventually postgres
will return with the result after a long time (hours later), however the
client has cancelled the WFS request.  Is there any way for mapserver to
know that the client has cancelled the http request, and it can therefore
stop the DB query to postgres?  I tried using persistent and non-persistent
connections with this:

PROCESSING "CLOSE_CONNECTION=DEFER"

but that didn't change the behavior.

Thanks a lot!
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/long-running-postgres-queries-initiated-by-mapserver-tp5855539p5855539.html

Sent from the Mapserver - User mailing list archive at Nabble.com.
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20101221/3ecbb4a6/attachment.htm>