Re: create table like: ACCESS METHOD

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers(at)postgresql(dot)org, Jacob Champion <pchampion(at)vmware(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: create table like: ACCESS METHOD
Date: 2020-12-29 23:08:05
Message-ID: 20201229230805.GE25152@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 25, 2020 at 03:41:46PM +0900, Michael Paquier wrote:
> On Wed, Dec 09, 2020 at 02:13:29PM -0600, Justin Pryzby wrote:
> > I thought this was a good idea, but didn't hear back when I raised it before.
> >
> > Failing to preserve access method is arguably a bug, reminiscent of CREATE
> > STATISTICS and 5564c1181. But maybe it's not important to backpatch a fix in
> > this case, since access methods are still evolving.
>
> Interesting. Access methods for tables are released for more than one
> year now, so my take about a backpatch is that this boat has already
> sailed. This may give a reason to actually not introduce this
> feature.

Are you saying that since v12/13 didn't preserve the access method, it might be
preferred to never do it ? I think it's reasonable to to not change v12/13 but
the behavior seems like an omission going forward. It's not so important right
now, since AMs aren't widely used.

This might be important for a few cases I can think of easily:

If an readonly AM doesn't support DDL, and table needs to be rebuilt, we'd
handle that by creating a new table LIKE the existing table, preserving its AM,
and then INSERT into it. Like for column type promotion. That's much better
than querying amname FROM pg_class JOIN relam.

ALTER TABLE..ATTACH PARTITION requires a less strong lock than CREATE
TABLE..PARTITION OF, so it's nice to be able to CREATE TABLE LIKE.

To use an alternate AM for historic data, we'd CREATE TABLE LIKE an existing,
populated table before inserting into it. This would support re-creating on a
new AM, or re-creating on the same AM, say, to get rid of dropped columns, or
to re-arrange columns.

> -- fail, as partitioned tables don't allow NO INHERIT constraints
> -CREATE TABLE noinh_con_copy1_parted (LIKE noinh_con_copy INCLUDING ALL)
> +CREATE TABLE noinh_con_copy1_parted (LIKE noinh_con_copy INCLUDING ALL EXCLUDING ACCESS METHOD)
> PARTITION BY LIST (a);
> This diff means that you are introducing an incompatible change by
> forcing any application using CREATE TABLE LIKE for a partitioned
> table to exclude access methods. This is not acceptable, and it may
> be better to just ignore this clause instead in this context.

Ok. This means that
CREATE TABLE (LIKE x INCLUDING ACCESS METHOD) PARTITION BY ...
silently ignores the INCLUDING AM. Is that ok ? I think the alternative is
for INCLUDING to be "ternary" options, defaulting to UNSET=0, when it's ok to
ignore options in contexts where they're not useful.
Maybe we'd need to specially handle INCLUDING ALL, to make options
"soft"/implied rather than explicit.

> This patch should have more tests. Something could be added in
> create_am.sql where there is a fake heap2 as table AM.

Yes, I had already done that locally.

--
Justin

Attachment Content-Type Size
v2-0001-create-table-like-.-including-ACCESS-METHOD.patch text/x-diff 7.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2020-12-29 23:53:46 Re: Parallel Inserts in CREATE TABLE AS
Previous Message Tom Lane 2020-12-29 23:05:20 Re: Better client reporting for "immediate stop" shutdowns