| 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-17 19:05:03 |
| Message-ID: | ZpgV32NTM0ADvJop@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 17, 2024 at 02:59:26PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>> On second thought, I worry that this change might needlessly complicate the
>> pg_sequences system view. Maybe we should just add a
>> pg_sequence_get_tuple() function that returns everything in
>> FormData_pg_sequence_data for a given sequence OID...
>
> Uh ... why do we need a function, rather than just
>
> select * from pg_sequence
We can use that for dumpSequence(), but dumpSequenceData() requires
information from the sequence tuple itself. Right now, we query each
sequence relation individually for that data, and I'm trying to find a way
to cut down on those round trips.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-07-17 19:11:47 | Re: improve performance of pg_dump with many sequences |
| Previous Message | Alexander Lakhin | 2024-07-17 19:00:00 | Re: [EXTERNAL] Re: Add non-blocking version of PQcancel |