Re: Thinking about EXPLAIN ALTER TABLE
| От | Simon Riggs |
|---|---|
| Тема | Re: Thinking about EXPLAIN ALTER TABLE |
| Дата | |
| Msg-id | CANP8+jLqXTZkNcVLzUddh6wnPPWVcx2KnSD9mC7R=NoOkM_ZaA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Thinking about EXPLAIN ALTER TABLE (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Ответы |
Re: Thinking about EXPLAIN ALTER TABLE
|
| Список | 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: