On 12/7/18, Greg Stark <st...@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
