[postgis-users] OT: Question on performance in plpgsql function
Stephen Woodbridge
woodbri at swoodbridge.com
Mon Sep 5 20:26:41 PDT 2011
Hi all,
This may be a little off topic, but there are a lot of smart minds here
that might know.
I have a plpgsql function the does some work to compute all the
intersections with street names in a road network. It creates a vertex
table like in pgrouting and an intersection table. Then populates the
tables from a streets network and finally updates the intersection table
based on the number of connected segments that have names.
The performance issue I'm having is that if I include the final update
in the procedure is takes forever (well longer than 12 hours when I
aborted it) and postgres runs at 100 CPU for all that time. But if I
comment out the update and run the procedure it takes say 1 hour to run,
and then I then run the update from the command line it takes say
another hour to run that, so a total of 2 hours.
plpgsql function run in a single transaction and breaking it into two
steps does it in two transaction, so I figure that has something to do
with it. An you can not COMMIT in a plpgsql function.
Any thoughts on how to fix this?
Can a SQL procedure do a COMMIT? If so I might be able to reorg the
process into two some plpgsql procedures that get called from a SQL
procedure.
Thoughts?
-Steve
More information about the postgis-users
mailing list