From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Nikita The Spider The Spider" <nikitathespider(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 5 minutes to pg_dump nothing |
Date: | 2007-09-23 21:07:13 |
Message-ID: | 8944.1190581633@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Nikita The Spider The Spider" <nikitathespider(at)gmail(dot)com> writes:
> I think I found the problem. getTypes() calls findFuncByOid() twice
> for each item it sees. A comment at the top of findFuncByOid() says,
> "should hash this, but just do linear search for now". So that funtion
> is O(n)/2 where n = the # of functions found by the query in
> getFuncs(), and since it's called twice for each item in getTypes, the
> overall performance is O(m * n) where n = # of functions and m = # of
> types. As I said before, I have ~56000 items in pg_type and the query
> at the top of getFuncs returns ~98000 rows so for me performance is
> O(5.4 billion)-ish.
Hah, so you need *both* a lot of types and a lot of functions to have
a problem.
> Thanks for your help! Given that this problem seems to be triggered by
> a sort of edge case and the fix is non-trivial, I guess I should not
> expect a new version of pg_dump soon?
We might look into fixing it for 8.3, but I doubt we'd risk back-patching
such a change to older branches.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-23 23:42:45 | Re: 5 minutes to pg_dump nothing |
Previous Message | Nikita The Spider The Spider | 2007-09-23 20:37:45 | Re: 5 minutes to pg_dump nothing |