Re: pg_dump: optimize dumpFunc()
| От | Neil Conway |
|---|---|
| Тема | Re: pg_dump: optimize dumpFunc() |
| Дата | |
| Msg-id | CAOW5sYYpnX-gP6decg5M5zaS2d-tT0SW1PL+tNKXDX93eSfMYQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_dump: optimize dumpFunc() (Nathan Bossart <nathandbossart@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Aug 2, 2024 at 4:00 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Fri, Aug 02, 2024 at 01:33:45AM -0400, Tom Lane wrote:
> 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?
Hm. I think this is sufficient reason to withdraw this patch on the spot.
We could potentially rework the list of dumpable objects so that each list item represents one or more objects of the same type that we can fetch via a single query. We could then make whatever tradeoff we want in terms of fetch batch size vs client-side memory consumption.
Debatable whether it is worth the hit to code readability though, and might be a bit grotty to do the tsort we need to do for dependency handling...
Neil
В списке pgsql-hackers по дате отправления: