Re: ALTER tbl rewrite loses CLUSTER ON index - Mailing list pgsql-hackers

From Amit Langote
Subject Re: ALTER tbl rewrite loses CLUSTER ON index
Date
Msg-id CA+HiwqEEeehFhti-gV5We5uFeqp+TxTbAMvsUSHiGhj2_U57sQ@mail.gmail.com
Whole thread Raw
In response to ALTER tbl rewrite loses CLUSTER ON index  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: ALTER tbl rewrite loses CLUSTER ON index
Re: ALTER tbl rewrite loses CLUSTER ON index
List pgsql-hackers
Hi Justin,

On Mon, Feb 3, 2020 at 1:17 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> Other options are preserved by ALTER (and CLUSTER ON is and most obviously
> should be preserved by CLUSTER's rewrite), so I think (SET) CLUSTER should be
> preserved by ALTER, too.

Yes.

create table foo (a int primary key);
cluster foo;
ERROR:  there is no previously clustered index for table "foo"
cluster foo using foo_pkey;
alter table foo alter a type bigint;
cluster foo;
ERROR:  there is no previously clustered index for table "foo"

With your patch, this last error doesn't occur.

Like you, I too suspect that losing indisclustered like this is
unintentional, so should be fixed.

> As far as I can see, this should be the responsibility of something in the
> vicinity of ATPostAlterTypeParse/RememberIndexForRebuilding.
>
> Attach patch sketches a fix.

While your sketch hits pretty close, it could be done a bit
differently.  For one, I don't like the way it's misusing
changedIndexOids and changedIndexDefs.

Instead, we can do something similar to what
RebuildConstraintComments() does for constraint comments.  For
example, we can have a PreserveClusterOn() that adds a AT_ClusterOn
command into table's AT_PASS_OLD_INDEX pass commands.  Attached patch
shows what I'm thinking.  I also added representative tests.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Next
From: Julien Rouhaud
Date:
Subject: Re: Expose lock group leader pid in pg_stat_activity