From: Stephen Frost <sfrost@snowman.net>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: predefined role(s) for VACUUM and ANALYZE
Date: Wed, 7 Sep 2022 17:13:44 -0400
Message-ID: <20220907211343.GE26002@tamriel.snowman.net> (raw)
In-Reply-To: <20220906155432.GA1963795@nathanxps13>
References: <20220725164049.GA4091959@nathanxps13>
<20220726.104712.912995710251150228.horikyota.ntt@gmail.com>
<CA+Tgmoa5A4+OVCm5Uiwgd2=M=zNT6nSxA2xh_60=UY5xKttJsA@mail.gmail.com>
<CAKFQuwZKDSnFsz8d_3YLJpZH8xnD3N4qS-Qv2Us+sK0Ry4fPhQ@mail.gmail.com>
<CA+Tgmoa7jS1uvq2s+GLWbCT6e1wH2thfSBHbsF88rtg+Dd4PaQ@mail.gmail.com>
<20220823234647.GB31055@tamriel.snowman.net>
<20220905185630.GA1961927@nathanxps13>
<20220906151151.GB26002@tamriel.snowman.net>
<CA+Tgmobi96u71+ChcrtGoymwp=9YzMGCu_vhnDp_avawV96Uyw@mail.gmail.com>
<20220906155432.GA1963795@nathanxps13>
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
Attachments:
[application/pgp-signature] signature.asc (818B, ../20220907211343.GE26002@tamriel.snowman.net/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, nathandbossart@gmail.com, robertmhaas@gmail.com, david.g.johnston@gmail.com, horikyota.ntt@gmail.com, bharath.rupireddyforpostgres@gmail.com
Subject: Re: predefined role(s) for VACUUM and ANALYZE
In-Reply-To: <20220907211343.GE26002@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox