Re: improve performance of pg_dump with many sequences
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Euler Taveira <euler@eulerto.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-07-16T21:36:15Z
Lists: pgsql-hackers
Attachments
- v3-0001-parse-sequence-information.patch (text/plain)
On Thu, Jul 11, 2024 at 09:09:17PM -0500, Nathan Bossart wrote: > On second thought, maybe we should just limit this improvement to the minor > releases with the fix so that we _can_ get rid of the workaround. Or we > could use the hacky workaround only for versions with the bug. Here is a new version of the patch set. The main differences are 1) we no longer gather the sequence data for schema-only dumps and 2) 0003 uses a simplified query for dumps on v18 and newer. I considered also using a slightly simplified query for dumps on versions with the unlogged-sequences-on-standbys fix, but I felt that wasn't worth the extra code. Unfortunately, I've also discovered a problem with 0003. pg_sequence_last_value() returns NULL when is_called is false, in which case we assume last_value == seqstart, which is, sadly, bogus due to commands like ALTER SEQUENCE [RE]START WITH. AFAICT there isn't an easy way around this. We could either create a giant query that gathers the information from all sequences in the database, or we could introduce a new function in v18 that returns everything we need (which would only help for upgrades _from_ v18). Assuming I'm not missing a better option, I think the latter is the better choice, and I still think it's worth doing even though it probably won't help anyone for ~2.5 years. -- nathan
Commits
-
pg_dump: Fix gathering of sequence information.
- 7a485bd641b7 19 (unreleased) landed
- 39d55557661f 18.2 landed
-
Improve performance of dumpSequence().
- 68e962998598 18.0 landed
-
Improve performance of dumpSequenceData().
- bd15b7db489d 18.0 landed
-
Introduce pg_sequence_read_tuple().
- c8b06bb969bf 18.0 landed
-
Parse sequence type and integer metadata in dumpSequence().
- 23687e925f94 18.0 landed