From: | John Naylor <jcnaylor(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Thinking about EXPLAIN ALTER TABLE |
Date: | 2018-12-07 23:22:12 |
Message-ID: | CAJVSVGU2J+WaafmCB=VvjrU_+sMhk+cVhjRjXN=Xe-H9FOPrBA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/7/18, Greg Stark <stark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-12-07 23:25:29 | Dead code in toast_fetch_datum_slice? |
Previous Message | Michael Paquier | 2018-12-07 23:05:40 | Re: pg_partition_tree crashes for a non-defined relation |