Re: Thinking about EXPLAIN ALTER TABLE - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Thinking about EXPLAIN ALTER TABLE
Date
Msg-id CANP8+jLqXTZkNcVLzUddh6wnPPWVcx2KnSD9mC7R=NoOkM_ZaA@mail.gmail.com
Whole thread Raw
In response to Re: Thinking about EXPLAIN ALTER TABLE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Thinking about EXPLAIN ALTER TABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 10 Dec 2018 at 16:14, Alvaro Herrera <alvherre@2ndquadrant.com> 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 where it's hardest to
> predict are precisely where users would most like to know what's going
> to happen...

Maybe you can move some of these decisions to phase 1, but I'm not sure
it can be done for all of them.  Another possible plan is to add a flag
"dry run" so that phases 2/3 do whatever analysis they need to report
for your EXPLAIN, but not actually carry out their tasks.  (I see two
options to implement this, one is a global flag and the other is a new
argument to all those routines.)

You need to take a table lock to find out things about the table.

EXPLAIN seems like the wrong place for this.

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. 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Pluggable Storage - Andres's take
Next
From: Tom Lane
Date:
Subject: Re: Thinking about EXPLAIN ALTER TABLE