On 2012-12-01 18:27:08 +0000, Simon Riggs wrote: > On 1 December 2012 16:38, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Simon Riggs <si...@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? > > That's the point. You run it on a test server first, and you can > conclusively see that it will/will not run for a long time on > production server. > > Greg Sabine Mullane wrote an interesting blog about a way of solving > the problem in userspace. > > > Or even more to the point, you can always cancel the statement once > > you realize it's taking too long. > > Which means you have to watch it, which is not always possible. > > > 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. > > I think it was an interesting idea, but I agree with comments about > weird syntax. > > We need something better and more general for impact assessment.
My first thought is to add more detailed EXPLAIN support for DDL... Although that unfortunately broadens the scope of this a tiny bit. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers