Re: ALTER TABLE ... NOREWRITE option

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE ... NOREWRITE option
Date: 2012-12-01 16:38:38
Message-ID: 15655.1354379918@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-12-01 16:38:40 Re: --single-transaction hack to pg_upgrade does not work
Previous Message Andres Freund 2012-12-01 16:36:20 Re: --single-transaction hack to pg_upgrade does not work