Re: pg_dump and thousands of schemas
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tatsuo Ishii <ishii@postgresql.org>, pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Date: 2012-05-31T04:18:17Z
Lists: pgsql-hackers, pgsql-performance
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Teach AbortOutOfAnyTransaction to clean up partially-started transactions.
- 2755abf386e6 9.2.0 cited
Stephen Frost <sfrost@snowman.net> writes: > The current situation where the client-to-server latency accounts for > multiple minutes of time is just ridiculous, however, so I feel we need > some form of this patch, even if the server side is magically made much > faster. The constant back-and-forth isn't cheap. No, you're missing my point. I don't believe that client-to-server latency, or any other O(N) cost, has anything to do with the problem here. The problem, as Jeff has demonstrated, is the O(N^2) costs associated with management of the local lock table. It is utterly pointless to worry about O(N) costs until that's fixed; and it's just wrong to claim that you've created a significant speedup by eliminating a constant factor when all you've done is staved off occurrences of the O(N^2) problem. Once we've gotten rid of the local lock table problem, we can re-measure and see what the true benefit of this patch is. I'm of the opinion that it will be in the noise compared to the overall runtime of pg_dump. I could be wrong, but you won't convince me of that with measurements taken while the local lock table problem is still there. regards, tom lane