Re: 5 minutes to pg_dump nothing

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

In response to

Responses

Browse pgsql-general by date

  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