Re: improve performance of pg_dump with many sequences

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: improve performance of pg_dump with many sequences
Дата
Msg-id ZpcsrAcClLt7AwdI@paquier.xyz
обсуждение исходный текст
Ответ на Re: improve performance of pg_dump with many sequences  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: improve performance of pg_dump with many sequences
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Injection points: preloading and runtime arguments
Следующее
От: feichanghong
Дата:
Сообщение: Re: temp table on commit delete rows performance issue