Re: pg_dump: optimize dumpFunc()
От | Nathan Bossart |
---|---|
Тема | Re: pg_dump: optimize dumpFunc() |
Дата | |
Msg-id | Zq067RVF_Zpicpc_@nathan обсуждение исходный текст |
Ответ на | Re: pg_dump: optimize dumpFunc() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump: optimize dumpFunc()
|
Список | pgsql-hackers |
On Fri, Aug 02, 2024 at 01:33:45AM -0400, Tom Lane wrote: > 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. Hm. I think this is sufficient reason to withdraw this patch on the spot. -- nathan
В списке pgsql-hackers по дате отправления: