From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Euler Taveira <euler(at)eulerto(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: improve performance of pg_dump with many sequences |
Date: | 2024-07-18 03:45:32 |
Message-ID: | ZpiP3I6UVcgsCCWf@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here is an attempt at adding a new function that returns the sequence tuple
and using that to avoid querying each sequence relation individually in
dumpSequenceData().
If we instead wanted to change pg_sequence_last_value() to return both
is_called and last_value, I think we could modify the pg_sequences system
view to use a LATERAL subquery, i.e.,
SELECT
...
CASE
WHEN L.is_called THEN L.last_value
ELSE NULL
END AS last_value
FROM pg_sequence S
...
JOIN LATERAL pg_sequence_last_value(S.seqrelid) L ON true
...
That doesn't seem so bad, and it'd avoid an extra pg_proc entry, but it
would probably break anything that calls pg_sequence_last_value() directly.
Thoughts?
--
nathan
Attachment | Content-Type | Size |
---|---|---|
v4-0001-parse-sequence-information.patch | text/plain | 4.0 KB |
v4-0002-cache-sequence-information.patch | text/plain | 7.9 KB |
v4-0003-introduce-pg_sequence_read_tuple.patch | text/plain | 4.4 KB |
v4-0004-cache-sequence-data.patch | text/plain | 5.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-07-18 03:55:37 | Re: Allow logical failover slots to wait on synchronous replication |
Previous Message | Paul Jungwirth | 2024-07-18 03:34:42 | Re: SQL:2011 application time |