[postgis-users] Long query execution time - is it OK?

Ben Madin ben at remoteinformation.com.au
Tue May 5 20:40:07 PDT 2009


G'day all,

I realise that there are probably many reasons, but I have a table  
with about 4 million tuples reflecting start and end point id's over  
two years.

I haven't been able to workable join these on the fly, so I have added  
three columns, one for the geometry of the start point, one for the  
geometry of the end point, and one for the (direct) line between them.

I then updated the start and end point columns (took around 20 minutes  
for each) by a UPDATE ... FROM ... JOIN syntax.

then this morning reduced the fillfactor of the table to 50% to try to  
make writes easier and I used st_makeline to create the third geometry  
(the line). the query plan didn't look very complex (unfortunately I  
didn't explain analyze):

update nlis set line_geom = st_makeline(s_geom, d_geom) where s_geom  
is not null and d_geom is not null;

                            QUERY PLAN
-----------------------------------------------------------------
  Seq Scan on nlis  (cost=0.00..194364.48 rows=3654306 width=246)
    Filter: ((s_geom IS NOT NULL) AND (d_geom IS NOT NULL))
(2 rows)

UPDATE 3701850

duration: 1 743 563.733 ms

Is 30 minutes reasonable for this sort of query?

I have increased max_connection, shared_buffers, effective cache size  
etc and kern.sysv.shmmax and kern.sysv.shmall and a few other tuning  
bits and pieces based on information at http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server 
. This is running on a 2.4 GHz Core Duo (Mac OS X) with 2GB RAM and I  
notice that the postgres process seems to only variably run between 10  
and 45% of total CPU. Disk writes seemed to come in packets every few  
seconds, with nothing much in between.

I could be worrying about nothing, but I see posts of people with  
millions and millions of records, so I guess I'm just checking.

cheers

Ben

-- 

Ben Madin
REMOTE INFORMATION

t : +61 8 9192 5455
f : +61 8 9192 5535
m : 0448 887 220
Broome   WA   6725

ben at remoteinformation.com.au



							Out here, it pays to know...





More information about the postgis-users mailing list