Re: Don't treate IndexStmt like AlterTable when DefineIndex is called from ProcessUtilitySlow.

From: 正华吕 <kainwen(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Don't treate IndexStmt like AlterTable when DefineIndex is called from ProcessUtilitySlow.
Date: 2022-11-17 23:31:18
Message-ID: CANerzAcS9Sd1Z0NZFirLr6ceorq1cVoEpQ-PrNq66pA4y1XY3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, thanks a lot for your reply!

> Why do you think this is an improvement?

I hit the issue in Greenplum Database (Massively Parallel Postgres),
the MPP architecture is that coordinator dispatch statement to segments.
The dispatch logic is quit different for AlterTable and CreateTableLike:

* alter table: for each sub command, it will not dispatch; later it will
dispatch
the alter table statement as a whole.
* for create table like statement, like `create table t (like t1 including
indexes);`
this statement's 2nd stmt, has to dispatch to segments, but now it is
treated
as alter table, the dispatch logic is broken for this case in Greenplum.

I look into the issue and Greenplum Database wants to keep align with
Upstream
as possible. That is why I ask if we can force it to false.

Best,
Zhenghua Lyu

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2022年11月18日周五 06:26写道:

> =?UTF-8?B?5q2j5Y2O5ZCV?= <kainwen(at)gmail(dot)com> writes:
> > Recently read the code, I find that when calling DefineIndex
> > from ProcessUtilitySlow, is_alter_table will be set true if
> > this statement is came from expandTableLikeClause.
>
> Yeah.
>
> > Based on the above, I think we can always a false value
> > for is_alter_table when DefineIndex is called from
> > ProcessUtilitySlow.
>
> Why do you think this is an improvement? Even if it's correct,
> the code savings is so negligible that I'm not sure I want to
> expend brain cells on figuring out whether it's correct. The
> comment you want to remove does not suggest that it's optional
> which value we should pass, so I think the burden of proof
> is to show that this patch is okay not that somebody else
> has to demonstrate that it isn't.
>
> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Li Japin 2022-11-18 00:10:25 Re: redundant check of msg in does_not_exist_skipping
Previous Message Peter Geoghegan 2022-11-17 22:57:12 Re: Standardizing how pg_waldump presents recovery conflict XID cutoffs