On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote: >> On 18 Apr 2024, at 06:17, Nathan Bossart <nathandboss...@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