<p>Stephen, this is just a wild guess and going from memory to boot...</p>
<p>I believe there can be an issue with pgsql where the reader and writer processes interfere with each other and the writer "stalls".</p>
<p>There are ways to detect this if it is happening and configuration parameters to set that are meant to help.</p>
<p>It seems to me we have run across this in our shop when we have update processes running through an entire long (and maybe wide) table.</p>
<p>Perhaps this is at the root of your problem.</p>
<div class="gmail_quote">On Sep 6, 2011 6:39 AM, "Stephen Woodbridge" <<a href="mailto:woodbri@swoodbridge.com">woodbri@swoodbridge.com</a>> wrote:<br type="attribution">> On 9/5/2011 11:26 PM, Stephen Woodbridge wrote:<br>
>> Hi all,<br>>><br>>> This may be a little off topic, but there are a lot of smart minds here<br>>> that might know.<br>>><br>>> I have a plpgsql function the does some work to compute all the<br>
>> intersections with street names in a road network. It creates a vertex<br>>> table like in pgrouting and an intersection table. Then populates the<br>>> tables from a streets network and finally updates the intersection table<br>
>> based on the number of connected segments that have names.<br>>><br>>> The performance issue I'm having is that if I include the final update<br>>> in the procedure is takes forever (well longer than 12 hours when I<br>
>> aborted it) and postgres runs at 100 CPU for all that time. But if I<br>>> comment out the update and run the procedure it takes say 1 hour to run,<br>>> and then I then run the update from the command line it takes say<br>
>> another hour to run that, so a total of 2 hours.<br>> <br>> OK, so here are some real numbers as i just aborted it after 48000 sec <br>> and rerunning part one without the update took 460 sec. and then running <br>
> the update alone took 75 sec. So aborted at about 13 hrs vs completing <br>> in two steps in 9 minutes.<br>> <br>> And after reading the docs some more I can not do a commit in any stored <br>> procedure, I guess I will have to wrap the two commands into a <br>
> client-side script, unless anyone has any other ideas on why this is <br>> happening.<br>> <br>> -Steve<br>> <br>>> plpgsql function run in a single transaction and breaking it into two<br>>> steps does it in two transaction, so I figure that has something to do<br>
>> with it. An you can not COMMIT in a plpgsql function.<br>>><br>>> Any thoughts on how to fix this?<br>>> Can a SQL procedure do a COMMIT? If so I might be able to reorg the<br>>> process into two some plpgsql procedures that get called from a SQL<br>
>> procedure.<br>>><br>>> Thoughts?<br>>><br>>> -Steve<br>>> _______________________________________________<br>>> postgis-users mailing list<br>>> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>> <br>> _______________________________________________<br>> postgis-users mailing list<br>
> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div>