Stephen Frost <sfrost@xxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
