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 по дате отправления: