Thread: 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