Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change
Date: 2015-11-17 19:02:48
Message-ID: CA+TgmoY0GAiSHSSh8nW07+WNAMwhsovCXqwyczgmN=z8fq18_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 16, 2015 at 4:27 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> Thank you so much for the review and patch update. I should have done that
> myself, but I've been really busy for the last few weeks. :(

Maybe I'm having an attack of the stupids today, but it looks to me
like the changes to pg_constraint.c look awfully strange to me. In
the old code, if object_address_present() returns true, we continue,
skipping the rest of the loop. In the new code, we instead set
alreadyChanged to true. That causes both of the following if
statements, as revised, to fall out, so that we skip the rest of the
loop. Huh? Wouldn't a one line change to add oldNspId != newNspId to
the criteria for a simple_heap_update be just as good?

Backing up a bit, maybe we should be a bit more vigorous in treating a
same-namespace move as a no-op. That is, don't worry about calling
the post-alter hook in that case - just have AlterConstraintNamespaces
start by checking whether oldNspId == newNspid right at the top; if
so, return. The patch seems to have the idea that it is important to
call the post-alter hook even in that case, but I'm not sure whether
that's true. I'm not sure it's false, but I'm also not sure it's
true.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-11-17 19:10:00 Re: pg_receivexlog: spurious error message connecting to 9.3
Previous Message Peter Geoghegan 2015-11-17 18:59:05 Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?