Alvaro Herrera <alvhe...@commandprompt.com> writes: > Excerpts from Tom Lane's message of lun oct 03 01:47:18 -0300 2011: >> (Without cassert, it looks like LockReassignCurrentOwner is the next >> biggest time sink; I'm wondering if there's some sort of O(N^2) behavior >> in there.)
> That seems fishy. Even if there weren't quadratic behavior, should this > be called at all? AFAIK it should only be used on cases where there are > subtransactions at work, and I don't think pg_dump uses them. I wondered that too, but the calls are legit --- they're coming from PortalDrop. It appears that most of the calls don't actually have anything to do, but they're iterating through a rather large local lock table to find that out. We probably ought to think of a way to avoid that. The trick is to not make performance worse for typical small transactions that aren't holding many locks (which I think was the design center for this to begin with). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers