Re: improve performance of pg_dump with many sequences

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 18:22:10
Message-ID: ZpldUoP0XjHszExF@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 17, 2024 at 11:58:21PM -0400, Tom Lane wrote:
> ... okay, I lied, I looked at the patch. Why are you testing
>
> + if (pg_class_aclcheck(relid, GetUserId(), ACL_SELECT | ACL_USAGE) == ACLCHECK_OK &&
>
> ? This is a substitute for a SELECT from the sequence and it seems
> like it ought to demand exactly the same privilege as SELECT.
> (If you want to get more technical, USAGE allows nextval() which
> gives strictly less information than what this exposes; that's why
> we're here after all.) So there is a difference in the privilege
> levels, which is another reason for not combining this with
> pg_sequence_last_value.

Oh, that's a good point. I wrongly assumed the privilege checks would be
the same as pg_sequence_last_value(). I fixed this in v5.

I also polished the rest of the patches a bit. Among other things, I
created an enum for the sequence data types to avoid the hacky strncpy()
stuff, which was causing weird CI failures [0].

[0] https://cirrus-ci.com/task/4614801962303488

--
nathan

Attachment Content-Type Size
v5-0001-parse-sequence-information.patch text/plain 5.9 KB
v5-0002-cache-sequence-information.patch text/plain 10.2 KB
v5-0003-introduce-pg_sequence_read_tuple.patch text/plain 4.4 KB
v5-0004-cache-sequence-data.patch text/plain 4.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-07-18 18:38:22 Re: Seq scan instead of index scan querying single row from primary key on large table
Previous Message Tom Lane 2024-07-18 18:21:30 Re: Lock-free compaction. Why not?