Re: improve performance of pg_dump with many sequences
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Euler Taveira <euler@eulerto.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-08T17:36:38Z
Lists: pgsql-hackers
Attachments
On Wed, Jan 07, 2026 at 07:24:52PM -0500, Tom Lane wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: >> On Wed, Jan 07, 2026 at 06:13:48PM -0500, Tom Lane wrote: >>> That would be a fine argument were it not that collectSequences() >>> tries to vacuum up the data for every sequence in the DB, whether >>> the user has asked to dump them all or not. > >> I meant that we could teach pg_dump to error in dumpSequenceData() if it >> sees nulls for the sequence in question. > > Ah, gotcha; I thought you were talking about changing > pg_get_sequence_data() to throw an error instead of returning nulls. Here is a patch that does this along with what you described upthread, i.e., teaching pg_get_sequence_data to return nulls for missing sequences. Apparently pg_dump still runs through dumpSequenceData() for schema-only dumps, which is a problem for this patch. I've taught it to immediately return for schema-only dumps to evade this problem. That seems like a win for older versions, too, as they will no longer run useless queries. I believe this helps the reporter's case, as their problem involves dumping one schema while dropping another, which v18 indeed makes worse because (as you mentioned) we gather data for all sequences in the database. -- 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