Re: pg_dump: optimize dumpFunc() - Mailing list pgsql-hackers

From Neil Conway
Subject Re: pg_dump: optimize dumpFunc()
Date
Msg-id CAOW5sYYpnX-gP6decg5M5zaS2d-tT0SW1PL+tNKXDX93eSfMYQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump: optimize dumpFunc()  (Nathan Bossart <nathandbossart@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix inappropriate uses of atol()
Next
From: Dmitry Dolgov
Date:
Subject: Re: Adding skip scan (including MDAM style range skip scan) to nbtree