Re: pg_dump: optimize dumpFunc()

From: Neil Conway <neil(dot)conway(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump: optimize dumpFunc()
Date: 2024-08-03 18:50:14
Message-ID: CAOW5sYYpnX-gP6decg5M5zaS2d-tT0SW1PL+tNKXDX93eSfMYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 2, 2024 at 4:00 PM Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2024-08-03 19:34:54 Re: Adding skip scan (including MDAM style range skip scan) to nbtree
Previous Message Tom Lane 2024-08-03 16:05:59 Re: Fix inappropriate uses of atol()