On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote:
>> On 18 Apr 2024, at 06:17, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
>> The attached work-in-progress patch speeds up 'pg_dump --binary-upgrade'
>> for this case. Instead of executing the query in every call to the
>> function, we can execute it once during the first call and store all the
>> required information in a sorted array that we can bsearch() in future
>> calls.
>
> That does indeed seem like a saner approach. Since we look up the relkind we
> can also remove the is_index parameter to binary_upgrade_set_pg_class_oids
> since we already know that without the caller telling us?
Yeah. It looks like that's been possible since commit 9a974cb, so I can
write a prerequisite patch for this.
>> One downside of this approach is the memory usage.
>
> I'm not too worried about the worst-case performance of this.
Cool. That seems to be the general sentiment.
>> This was more-or-less
>> the first approach that crossed my mind, so I wouldn't be surprised if
>> there's a better way. I tried to keep the pg_dump output the same, but if
>> that isn't important, maybe we could dump all the pg_class OIDs at once
>> instead of calling binary_upgrade_set_pg_class_oids() for each one.
>
> Without changing the backend handling of the Oid's we can't really do that
> AFAICT, the backend stores the Oid for the next call so it needs to be per
> relation like now?
Right, this would require additional changes.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
