Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 21 Feb 2024 15:40:18 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	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: <ZdWa0sSExPfBvAyR@paquier.xyz>
References: <ZCIxFkgOGv64nYE7@paquier.xyz>
 <ZCJuW3GOfE/0eBjh@telsasoft.com>
 <ZCUZLiCeXq4Im7OG@telsasoft.com>
 <ZEccbkBYCMy42Rxt@telsasoft.com>
 <ZG8E6DggGkPyEPPx@paquier.xyz>
 <ZHfZxjcR0J9Ws7ze@telsasoft.com>
 <ZHiUKhhT71X4CjJl@paquier.xyz>
 <ZLgn3Ou4YpgP8Z8l@telsasoft.com>
 <d1cb16ec-9af1-4657-81f2-865480d2bd6d@eisentraut.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="QG0JSu0iMg4ikH9Y"
Content-Disposition: inline
In-Reply-To: <d1cb16ec-9af1-4657-81f2-865480d2bd6d@eisentraut.org>
Archived-At: <https://www.postgresql.org/message-id/ZdWa0sSExPfBvAyR%40paquier.xyz>
Precedence: bulk


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

On Tue, Feb 20, 2024 at 03:47:46PM +0100, Peter Eisentraut wrote:
> It would be helpful if this patch could more extensively document in its
> commit message what semantic changes it makes.  Various options of possib=
le
> behaviors were discussed in this thread, but it's not clear which behavio=
rs
> were chosen in this particular patch version.
>=20
> The general idea is that you can set an access method on a partitioned
> table.  That much seems very agreeable.  But then what happens with this
> setting, how can you override it, how can you change it, what happens when
> you change it, what happens with existing partitions and new partitions,
> etc. -- and which of these behaviors are new and old.  Many things to
> specify.

The main point in this patch is the following code block in
DefineRelation(), that defines the semantics about the AM set for a
partitioned table:
+    else if (RELKIND_HAS_TABLE_AM(relkind) || relkind =3D=3D RELKIND_PARTI=
TIONED_TABLE)
     {
+        if (stmt->partbound)
+        {
+            /*
+             * For partitions, if no access method is specified, use the A=
M of
+             * the parent table.
+             */
+            Assert(list_length(inheritOids) =3D=3D 1);
+            accessMethodId =3D get_rel_relam(linitial_oid(inheritOids));
+            Assert(OidIsValid(accessMethodId));
+        }
+        else
+            accessMethodId =3D get_table_am_oid(default_table_access_metho=
d, false);
     }

This means that all partitioned tables would have pg_class.relam set,
and that relam would never be 0:
- The USING clause takes priority over default_table_access_method.
- If no USING clause, default_table_access_method is the AM used

Any partitions created from this partitioned table would inherit the
AM set, ignoring default_table_access_method. =20

Alvaro has made a very good point a couple of days ago at [1] where we
should try to make the behavior stick closer to tablespaces, where it
could be possible to set relam to 0 for a partitioned table, where a
partition would inherit the AM set in the GUC when a USING clause is
not defined (if USING specifies the AM, we'd just use it).

Existing partitions should not be changed if the AM of their
partitioned table changes, so you can think of the AM as a hint for
the creation of new partitions.

[1]: https://www.postgresql.org/message-id/202402011550.sfszd46247zi@alvher=
re.pgsql
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmXVmtIACgkQnvQgOdby
QH032w//eUZup4UpA6jrfm+mIwIPIM8BKuEgn1+LkUZdHumlCGxQJzMyQ2adct1B
swvv9rpqNvjy8e3+trvn7CZUibJzAhLB5b4P/aLOB/wY0wQJuckcsaqiELSTHLsh
mIWZ+u61Kc3cZGPjlF0/+P93OzAiqgKsGSDiAP0JltJ4GED48Y3dT8dpdaD9G9yo
b5mNkYvjcmB+dx9m/32R6peJu6XyI4qgqx517sgu70vyhNHJBmgQNSmK245DtuEg
3ZnDXaQ8G2WBZODkg054Wfp+uE0J1BRGoMqJzUEyRWuIqLxm+sF49MZjHqMu9SgC
/SpmoMsWL6JTEMWpbDGDNBBOXI6QafR8uTCn/CV9+KJrBjt9s9FXd4I9FxWiILx1
IogVdHrTq9ARD9+zHJ7hFORQJxKeWAO8G7/n7aoFNwzgfbkWXL1NOyUATO+oWWdY
YvYNNGUAHlcGVkEFFJfDrlmgQDpi0fVP77S8vqPmL1yNAb98CdpoBa6TftOn6u7k
O55Jz09X0izg+bEJvNDOey6AwNKd7vhsd/QPeqxwGFf70Zu+mXhTQyYou5Muerq3
2eCrpJHp/EFxyZ3ynCjRtmvko8sFnvaBl6OJYkPIo1Ubj5F91rbEDeLeodefiqSE
sOf4faGmAvFA00/v0+YoOUvyWv2DbvGV/mbBy0CJivHTwx4H5B0=
=IUdE
-----END PGP SIGNATURE-----

--QG0JSu0iMg4ikH9Y--