Re: Thinking about EXPLAIN ALTER TABLE

2019-01-06 Thread Greg Stark
On Mon, 10 Dec 2018 at 11:14, Alvaro Herrera wrote: > > Hi Greg > > On 2018-Dec-07, Greg Stark wrote: > > > I'm thinking I should try to move all these decisions to phase 1 as > > much as possible but I'm not sure how feasible it will be to get the > > results exactly correct. Of course the cases

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-11 Thread Alvaro Herrera
On 2018-Dec-11, Jose Luis Tallon wrote: > * EXPLAIN PERFORM ALTER TABLE    (EXPLAIN EXEC?)    would explain + do > >     ...and bonus points for explaining each step just before it is > performed. This way, It'd be easy for users to verify that a particular step > (i.e. table rewrite) is the one

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-11 Thread Jose Luis Tallon
We were just busy shooting down a different suggestion of behavior-changing GUCs. A GUC that turns all ALTERs into no-ops sure seems like a foot-gun to me. Yeah, I like EXPLAIN better. +1 for EXPLAIN IMVHO, and for "symmetry" with existing mechanisms: * EXPLAIN ALTER TABLE    ==> "DDL dry ru

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread David Fetter
On Tue, Dec 11, 2018 at 11:25:12AM +0900, Robert Haas wrote: > On Tue, Dec 11, 2018 at 1:32 AM Tom Lane wrote: > > Simon Riggs writes: > > > I suggest ALTER TABLE should respond to a parameter setting of ddl_dry_run > > > = on, so the whole world doesn't need to rewrite its syntax to support the

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Michael Paquier
On Tue, Dec 11, 2018 at 11:25:12AM +0900, Robert Haas wrote: > Yeah, I like EXPLAIN better. +1. -- Michael signature.asc Description: PGP signature

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Robert Haas
On Tue, Dec 11, 2018 at 1:32 AM Tom Lane wrote: > Simon Riggs writes: > > I suggest ALTER TABLE should respond to a parameter setting of ddl_dry_run > > = on, so the whole world doesn't need to rewrite its syntax to support the > > new option. > > We were just busy shooting down a different sugge

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Greg Stark
On Mon, 10 Dec 2018 at 12:27, Simon Riggs wrote: > > An event trigger with a table_rewrite event, allows you to scan a whole > script for objectionable activity on a test server before you put it into > production. > > Perhaps we just need a few extra events. That's not a bad idea at all. Offha

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Simon Riggs
On Mon, 10 Dec 2018 at 16:52, Tom Lane wrote: > Simon Riggs writes: > > On Mon, 10 Dec 2018 at 16:32, Tom Lane wrote: > >> We were just busy shooting down a different suggestion of > >> behavior-changing GUCs. A GUC that turns all ALTERs into no-ops > >> sure seems like a foot-gun to me. > > >

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Tom Lane
Simon Riggs writes: > On Mon, 10 Dec 2018 at 16:32, Tom Lane wrote: >> We were just busy shooting down a different suggestion of >> behavior-changing GUCs. A GUC that turns all ALTERs into no-ops >> sure seems like a foot-gun to me. > How would you test a script? Manually edit each one with the

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Simon Riggs
On Mon, 10 Dec 2018 at 16:32, Tom Lane wrote: > Simon Riggs writes: > > I suggest ALTER TABLE should respond to a parameter setting of > ddl_dry_run > > = on, so the whole world doesn't need to rewrite its syntax to support > the > > new option. > > We were just busy shooting down a different su

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Tom Lane
Simon Riggs writes: > I suggest ALTER TABLE should respond to a parameter setting of ddl_dry_run > = on, so the whole world doesn't need to rewrite its syntax to support the > new option. We were just busy shooting down a different suggestion of behavior-changing GUCs. A GUC that turns all ALTER

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Simon Riggs
On Mon, 10 Dec 2018 at 16:14, Alvaro Herrera wrote: > Hi Greg > > On 2018-Dec-07, Greg Stark wrote: > > > I'm thinking I should try to move all these decisions to phase 1 as > > much as possible but I'm not sure how feasible it will be to get the > > results exactly correct. Of course the cases w

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-10 Thread Alvaro Herrera
Hi Greg On 2018-Dec-07, Greg Stark wrote: > I'm thinking I should try to move all these decisions to phase 1 as > much as possible but I'm not sure how feasible it will be to get the > results exactly correct. Of course the cases where it's hardest to > predict are precisely where users would mos

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-07 Thread John Naylor
On 12/7/18, Greg Stark wrote: > I've been poking around with a feature I've wanted a number of times > in the past, "EXPLAIN ALTER TABLE". I believe I've seen your messages to that effect in the archives, so I've had it in the back of my mind as well. I think it could be very useful. > 3. Whethe

Re: Thinking about EXPLAIN ALTER TABLE

2018-12-07 Thread Peter Geoghegan
On Fri, Dec 7, 2018 at 1:18 PM Greg Stark wrote: > I've been poking around with a feature I've wanted a number of times > in the past, "EXPLAIN ALTER TABLE". The idea is that there are a bunch > of optimizations in ALTER TABLE to minimize the amount of work and > lock levels but it's really hard f

Thinking about EXPLAIN ALTER TABLE

2018-12-07 Thread Greg Stark
I've been poking around with a feature I've wanted a number of times in the past, "EXPLAIN ALTER TABLE". The idea is that there are a bunch of optimizations in ALTER TABLE to minimize the amount of work and lock levels but it's really hard for users to tell whether they've written their ALTER TABLE