Обсуждение: 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.comPostgreSQL 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.

Peter Eisentraut <peter_e@gmx.net> writes:
> Isn't the whole point of EXPLAIN to expose implementation artifacts in 
> the first place?

Touche ... I withdraw the complaint.
        regards, tom lane