Re: pg_dump: optimize dumpFunc()
От | Tom Lane |
---|---|
Тема | Re: pg_dump: optimize dumpFunc() |
Дата | |
Msg-id | 3903370.1722576825@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_dump: optimize dumpFunc() (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: pg_dump: optimize dumpFunc()
|
Список | pgsql-hackers |
Nathan Bossart <nathandbossart@gmail.com> writes: > I've recently committed some optimizations for dumping sequences and > pg_class information (commits 68e9629, bd15b7d, and 2329cad), and I noticed > that we are also executing a query per function in pg_dump. Commit be85727 > optimized this by preparing the query ahead of time, but I found that we > can improve performance further by gathering all the relevant data in a > single query. Here are the results I see for a database with 10k simple > functions with and without the attached patch: I'm a bit concerned about this on two grounds: 1. Is it a win for DBs with not so many functions? 2. On the other end of the scale, if you've got a *boatload* of functions, what does it do to pg_dump's memory requirements? I'm recalling my days at Salesforce, where they had quite a few thousand pl/pgsql functions totalling very many megabytes of source text. (Don't recall precise numbers offhand, and they'd be obsolete by now even if I did.) I'm not sure that the results you're showing justify taking any risk here. regards, tom lane
В списке pgsql-hackers по дате отправления: