Re: Thinking about EXPLAIN ALTER TABLE

On 12/7/18, Greg Stark <stark@mit.edu> 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. Whether a full table constraint validation is going to happen

Is it possible that this can occur via index-only scan and that this
feature could know that?

> For the most part ALTER TABLE is already structured such that this is
> pretty easy. It does a lot of preparatory work without doing catalog
> updates and I can just call that same preparatory work without calling
> the subsequent work phases.

One thing that came to mind: Since the input is not a plan tree, it
seems it would be more difficult to keep EXPLAIN in sync with
additional ALTER TABLE features. Do you have any thoughts about that?

> postgres***=# explain alter table t alter column i set not null;
> ┌─────────────────────────────────┐
> │           QUERY PLAN            │
> ├─────────────────────────────────┤
> │ Lock Level: AccessExclusiveLock │
> │ ALTER TABLE: t                  │
> │   Relation: t                   │
> │   Rewrite: none                 │
> │   Relation: t2                  │
> │   Rewrite: none                 │
> └─────────────────────────────────┘

In this example, I assume the two relations are partitions? With many
partitions, this could get unwieldy pretty fast. I imagine there could
be a shorthand notation.

-John Naylor