Re: improve performance of pg_dump with many sequences - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: improve performance of pg_dump with many sequences
Date
Msg-id ZpcsrAcClLt7AwdI@paquier.xyz
Whole thread Raw
In response to Re: improve performance of pg_dump with many sequences  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: improve performance of pg_dump with many sequences
List pgsql-hackers
On Tue, Jul 16, 2024 at 04:36:15PM -0500, Nathan Bossart wrote:
> 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.

Yeah, I have bumped on the same issue.  In the long term, I also think
that we'd better have pg_sequence_last_value() return a row with
is_called and the value scanned.  As you say, it won't help except
when upgrading from versions of Postgres that are at least to v18,
assuming that this change gets in the tree, but that would be much
better in the long term and time flies fast.

See 0001 as of this area:
https://www.postgresql.org/message-id/ZnPIUPMmp5TzBPC2%40paquier.xyz
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Injection points: preloading and runtime arguments
Next
From: feichanghong
Date:
Subject: Re: temp table on commit delete rows performance issue