Re: improve performance of pg_dump with many sequences
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Euler Taveira <euler@eulerto.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-08T18:19:39Z
Lists: pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes: > 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. Looks plausible to me. (I didn't test, just read the code.) One nitpicky point is that try_sequence_open() will still error out if it is given an OID that is a non-sequence relation. I think it'd be more desirable for it to close the relation again and return NULL. That's probably insignificant for pg_dump's usage, because we could only hit the case with very improbable OID wraparound timing. But I think our experience with catalog-inspection functions similar to pg_get_sequence_data is that it's usually better to return NULL than throw an error. regards, tom lane
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