Re: 5 minutes to pg_dump nothing
От | Tom Lane |
---|---|
Тема | Re: 5 minutes to pg_dump nothing |
Дата | |
Msg-id | 8944.1190581633@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 5 minutes to pg_dump nothing ("Nikita The Spider The Spider" <nikitathespider@gmail.com>) |
Ответы |
Re: 5 minutes to pg_dump nothing
|
Список | pgsql-general |
"Nikita The Spider The Spider" <nikitathespider@gmail.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
В списке pgsql-general по дате отправления: