Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 1 Mar 2024 14:03:48 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	Peter Eisentraut <peter@eisentraut.org>,
	Soumyadeep Chakraborty <soumyadeep2007@gmail.com>,
	Zhihong Yu <zyu@yugabyte.com>, pgsql-hackers@postgresql.org,
	Ashwin Agrawal <ashwinstar@gmail.com>, vanjared@vmware.com
Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Message-ID: <ZeFhtO3Ih7gtfy2i@paquier.xyz>
References: <ZHfZxjcR0J9Ws7ze@telsasoft.com>
 <ZHiUKhhT71X4CjJl@paquier.xyz>
 <ZLgn3Ou4YpgP8Z8l@telsasoft.com>
 <d1cb16ec-9af1-4657-81f2-865480d2bd6d@eisentraut.org>
 <ZdWa0sSExPfBvAyR@paquier.xyz>
 <cab23590-19d4-4895-9333-1c25f4194741@eisentraut.org>
 <Zd7qEUKkBVY0d2-4@paquier.xyz>
 <ZeCZ89xAVFeOmrQC@pryzbyj2023>
 <ZeE14kii-re1CSUk@paquier.xyz>
 <CAGECzQScYZLUrmxj2hHpkqZTSxmP+m4M5YgbT9Log6cytVfq4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="AjVHwQNah/tQKWz2"
Content-Disposition: inline
In-Reply-To: <CAGECzQScYZLUrmxj2hHpkqZTSxmP+m4M5YgbT9Log6cytVfq4w@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZeFhtO3Ih7gtfy2i%40paquier.xyz>
Precedence: bulk


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

On Fri, Mar 01, 2024 at 05:43:25AM +0100, Jelte Fennema-Nio wrote:
> I think we should set the AM OID explicitly. Because an important
> thing to consider is: What behaviour makes sense when later
> default_table_access_method is changed?

Per the latest discussion of the thread, we've kind of reached a
consensus that we should keep the current historical bevahior on
default, where relam remains at 0, causing new partitions to grab the
GUC as AM.  If we create a partitioned table attached to a partitioned
table, it should be 0 as well.  If the partitioned table has a non-0
relam, a new partitioned table created on it will inherit the same
non-0 value.=20

> I think if someone sets it explicitly on the partitioned table, they
> would want the AM of the partitioned table to stay the same when
> default_table_access_method is changed. Which requires storing the AM
> OID afaict.

If we allow relam to be non-0 for a partitioned table, it is equally
important to give users a way to reset it at will.  My point was a bit
more subtle than that.  For example, this sequence is clear to me:
SET default_table_access_method =3D 'foo';
ALTER TABLE part SET ACCESS METHOD DEFAULT;

The user wants to rely on the GUC, so relam should be 0, new
partitions created on it will use the GUC.

Now, what should this sequence mean?  See:
SET default_table_access_method =3D 'foo';
ALTER TABLE part SET ACCESS METHOD foo;

Should the relam be 0 because the user requested a match with the GUC,
or use the OID of the AM?  There has to be some difference with
tablespaces, because relations with physical storage (tables,
matviews) can use a reltablespace of 0, but AMs have to be set for
tables and matviews.

Fun topic, especially once coupled with the internals of tablecmds.c
that uses InvalidOid for the new access AM as a special value to work
as a no-op.
--
Michael

--AjVHwQNah/tQKWz2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmXhYbQACgkQnvQgOdby
QH1sOg//SJpbOyf2tVHHAah38ZcLK4ql+MIXQsIwls6GGFUOAtl5SnMg1L7IdcJ5
v1vHDqrbK7lLKD/aLHQiy56HR0wrlyLuxLsmyZzWUcigDa9aoeB0e3cAJSuKRLJV
6y8W+Cx0vAMH9N6SLPX5vF/rzFAVo/8jnIXmO2ix1ETwBNl+/AQYTPGL/mwOc4r+
/itu63wdZpYD3578oRoUxQuYoc6UwcDtvu+b3CI6e/1F/rJ51fB2XEytd2slJwrR
DfI+RZhgQ8lyWSqbOexu5RseBeYs0zOsEfahsDNdaif83Pb2rJp667HeTENu97AO
y6udxREsUAPhd/35H6nWg+bH+NWiU/4KuHmXpM2dSKciB/H/uu/RrTpHt4cBUzhN
4K8eTDhfOqh5BTh1a7r1/XWCfXxVfLrW9z27Cottle3F3dCeVtFrGSzF/ooy+QlQ
b14AFaBe0UST+ixhJkwlOoax/It7eInLx50YD2caCIGpy5vCQ7KNiglfCD1X1lDp
RTdfUA5nenjSuaBFGhsudyzss+3y75SlqqQaaqIKdzCo+1AgCuC1wfcB51J3ykPo
M6WcUFODVSQEx5kGwFvTqXCqpw2y/ij0ZTr1+3g0rEog/03akOZ981INx7a3ptRq
2HelY3PFdRGwW7dGDqfimSMcN4GUBWRFXYih1lrVvrC95upS82g=
=omhW
-----END PGP SIGNATURE-----

--AjVHwQNah/tQKWz2--