On Fri, Aug 2, 2024 at 4:00 PM Nathan Bossart
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 withd
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'
Nathan Bossart 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
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 i
