Re: ALTER TABLE ... NOREWRITE option - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TABLE ... NOREWRITE option
Date
Msg-id 15655.1354379918@sss.pgh.pa.us
Whole thread Raw
In response to ALTER TABLE ... NOREWRITE option  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: ALTER TABLE ... NOREWRITE option
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> It's hard to know whether your tables will be locked for long periods
> when implementing DDL changes.

> The NOREWRITE option would cause an ERROR if the table would be
> rewritten by the command.

> This would allow testing to highlight long running statements before
> code hits production.

I'm not thrilled about inventing YA keyword for this.  If you have a
problem with that sort of scenario, why aren't you testing your DDL
on a test server before you do it on production?

Or even more to the point, you can always cancel the statement once
you realize it's taking too long.

Also, I don't really like the idea of exposing syntax knobs for
what ought to be purely an internal optimization.  If someday the
optimization becomes unnecessary or radically different in behavior,
you're stuck with dead syntax.  Sometimes the knob is sufficiently
important to take that risk, but it doesn't seem to be so here.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: --single-transaction hack to pg_upgrade does not work
Next
From: Tom Lane
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL