Re: predefined role(s) for VACUUM and ANALYZE - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: predefined role(s) for VACUUM and ANALYZE
Date
Msg-id 20220907211343.GE26002@tamriel.snowman.net
Whole thread Raw
In response to Re: predefined role(s) for VACUUM and ANALYZE  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: predefined role(s) for VACUUM and ANALYZE
List pgsql-hackers
Greetings,

* Nathan Bossart (nathandbossart@gmail.com) wrote:
> On Tue, Sep 06, 2022 at 11:24:18AM -0400, Robert Haas wrote:
> > On Tue, Sep 6, 2022 at 11:11 AM Stephen Frost <sfrost@snowman.net> wrote:
> >> If we were to make the specific bits depend on the object type as I'm
> >> suggesting, then we'd have 8 bits used for relations (10 with the vacuum
> >> and analyze bits), leaving us with 6 remaining inside the existing
> >> uint32, or more bits available than we've ever used since the original
> >> implementation from what I can tell, or at least 15+ years.  That seems
> >> like pretty darn good future-proofing without a lot of complication or
> >> any change in physical size.  We would also be able to get rid of the
> >> question of "well, is it more valuable to add the ability to GRANT
> >> TRUNCATE on a relation, or GRANT CONNECT on databases" or other rather
> >> odd debates between ultimately very different things.
> >
> > I mostly agree with this. I don't think it's entirely clear how we
> > should try to get more bits going forward, but it's clear that we
> > cannot just forever hold our breath and refuse to find any more bits.
> > And of the possible ways of doing it, this seems like the one with the
> > lowest impact, so I think it likely makes sense to do this one first.
>
> +1.  My earlier note wasn't intended to suggest that one approach was
> better than the other, merely that there are a couple of options to choose
> from once we run out of bits.  I don't think this work needs to be tied to
> the VACUUM/ANALYZE stuff, but I am interested in it and hope to take it on
> at some point.

I disagree that we should put the onus for addressing this on the next
person who wants to add bits and just willfully use up the last of them
right now for what strikes me, at least, as a relatively marginal use
case.  If we had plenty of bits then, sure, let's use a couple of for
this, but that isn't currently the case.  If you want this feature then
the onus is on you to do the legwork to make it such that we have plenty
of bits.

My 2c anyway.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Vitaly Burovoy
Date:
Subject: Doc fix and adjustment for MERGE command
Next
From: David Rowley
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types