EXPLAIN CREATE TABLE AS
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
ExplainableStmt:
SelectStmt
| InsertStmt
| UpdateStmt
| DeleteStmt
| DeclareCursorStmt
+ | CreateAsStmt
| ExecuteStmt /* by default all are $$=$1 */
;
It's the same as SELECT INTO after all, which already works. Should
this be added?
On Thu, 2008-10-23 at 14:29 +0300, Peter Eisentraut wrote:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
Yes please.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Peter Eisentraut <peter_e@gmx.net> writes:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
This seems to me to be something that will look like a wart, not a
feature, from the user's point of view. You can't explain CREATE TABLE,
but you can explain CREATE TABLE AS? It's just weird. It feels to me
like exposing an implementation artifact.
regards, tom lane
Le jeudi 23 octobre 2008, Tom Lane a écrit :
Peter Eisentraut <peter_e@gmx.net> writes:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:This seems to me to be something that will look like a wart, not a
feature, from the user's point of view. You can't explain CREATE TABLE,
but you can explain CREATE TABLE AS? It's just weird. It feels to me
like exposing an implementation artifact.
As a user, I'm disagreeing about the weirdness of it. +1 for Peter's
initiative.
Regards,
--
dim
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:This seems to me to be something that will look like a wart, not a
feature, from the user's point of view. You can't explain CREATE TABLE,
but you can explain CREATE TABLE AS? It's just weird. It feels to me
like exposing an implementation artifact.
Isn't the whole point of EXPLAIN to expose implementation artifacts in
the first place? It shows the plan associated with a plannable
statement. Why are some statements plannable and some not? Why can you
explain DELETE and not TRUNCATE? Why can you explain INSERT, what is
plannable about that? Ah, there is INSERT ... SELECT. If you can plan
INSERT, can you plan SELECT INTO, right? Yes, that works. But CREATE
TABLE AS is the same, why won't that work? Should we prohibit
explaining SELECT INTO? So you can't explain SELECT INTO, but you can
explain SELECT? It's all very weird.
So it's not like this is not already quite implementation-dependent. We
expose the information that we have and let the user process it.
Someone who has advanced to the level of using EXPLAIN should be able to
tell the difference, and those who are maximally confused won't be
harmed by this addition any more than they already are.