Date: Wed, 7 Sep 2022 17:13:44 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: predefined role(s) for VACUUM and ANALYZE
Message-ID: <20220907211343.GE26002@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="3O1VwFp74L81IIeR"
Content-Disposition: inline
In-Reply-To: <20220906155432.GA1963795@nathanxps13>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220907211343.GE26002%40tamriel.snowman.net>
Precedence: bulk


--3O1VwFp74L81IIeR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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> wrot=
e:
> >> 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 vacu=
um
> >> 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.
> >=20
> > 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.
>=20
> +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

--3O1VwFp74L81IIeR
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJjGQmHAAoJEO1sijiDR2RVYz4P/1V9AmIKMQ2hjDfDHrVrFJvI
DAT8hD4iFv6pE6l8ESFhpDf59wA6h3DDuNhWp4Qzrm1Zee+4kVlDodH1tM1N95sO
BM6yNaueHOkS8dUz7e31E3FUt8aRdweuCabBUHNEHmlGoWy+f26pN1Oy3dUIr2d8
wfMC5c+agFOwPJZEd6I2wp4wJYU94AyaKGsrndQlv3B3k7IvhLP3e6SPZ6Cgik2e
FHfrWSfHa/PsE8T9BNaosKP15G7YbtQAKCOHy0CcqGuu8QPYo8pinqn+G53BemME
MLX7cmcJ9LSOQhs20J8DwmwsEiLqov1h4WEADilBOest2avABBNg/PYjwbwDHmQq
KRa4ImkltebAodQa7MTNBkA6OuvdNqXJZGbH7c9Xme8CuDB/HD1ZPI1WN5OWj83W
VUK8ivdYVdSUX8rCasOXnke+wskppEOOMTs4kYP/PIlw1FhVE68+kGdH9TDX3lZ+
gPsxaZ8HvQhCPiKqnqlcemhosi6dyQcUiyJzwTTVrEHkvxwqktjZ5cxpNse14nxe
b5ABCylheyky5MUyR/Q8a7gB34IZfrpuuPBUcoijntf3RmoI5JqliFu8Y9EldfeZ
R9J9MWCW6UB99sn2MgeyfoMykJbRXXqdvMOZo4a/DS2lSYl/hlVGUXl1xaX0/LwN
Lx1TvfJm/ZCcXHd/3O3g
=z+zw
-----END PGP SIGNATURE-----

--3O1VwFp74L81IIeR--