Thread

1. explain.c: why trace PlanState and Plan trees separately?

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-07-13T00:02:19Z

   Currently, the recursion in ExplainNode() goes to some lengths to chase
   down the PlanState and Plan trees independently.  This is a bit silly:
   we could just chase the PlanState tree, and use each PlanState's "plan"
   link when we needed to get to the matching Plan node.  I think this is a
   holdover from long ago when the code worked only with Plan trees --- the
   PlanState stuff was bolted on rather than replacing that logic entirely.
   But there is no capacity for EXPLAINing a Plan tree without having
   constructed a PlanState tree, and I don't foresee that we'd add one
   (for one reason, EXPLAIN depends on ExecutorStart to perform permissions
   checking for the referenced tables).  Any objections to getting rid of
   the separate Plan argument?
   
   The reason I'm on about this at the moment is that I think I see how to
   get ruleutils to print PARAM_EXEC Params as the referenced expression
   rather than $N ... but it depends on having the PlanState tree at hand.
   So fixing that will destroy any last shred of credibility there might
   be for EXPLAINing a Plan tree without PlanState.  In fact I'm thinking
   I need to change deparse_context_for_plan() to take a PlanState not a
   Plan.
   
   			regards, tom lane
   
   

2. Re: explain.c: why trace PlanState and Plan trees separately?

   Yeb Havinga <yebhavinga@gmail.com> — 2010-07-13T08:50:37Z

   Tom Lane wrote:
   > The reason I'm on about this at the moment is that I think I see how to
   > get ruleutils to print PARAM_EXEC Params as the referenced expression
   > rather than $N ...
   Wouldn't this obfuscate the plan more than printing subplan arguments at 
   the call site?
   
   regards,
   Yeb Havinga
   
   
   

3. Re: explain.c: why trace PlanState and Plan trees separately?

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-07-13T14:10:03Z

   Yeb Havinga <yebhavinga@gmail.com> writes:
   > Tom Lane wrote:
   >> The reason I'm on about this at the moment is that I think I see how to
   >> get ruleutils to print PARAM_EXEC Params as the referenced expression
   >> rather than $N ...
   
   > Wouldn't this obfuscate the plan more than printing subplan arguments at 
   > the call site?
   
   It would if subplans could have more than one call site, but they can't.
   
   I do intend to force qualification of Vars that are printed as a result
   of param expansion; for example consider a standard nestloop-with-
   inner-indexscan plan:
   
   	NestLoop
   		Seq Scan on a
   		Index Scan on b
   			Index Cond: x = a.y
   
   If y weren't qualified to show that it's not a variable of b, this could
   be confusing.  But as long as we do that, it pretty much matches our
   historical behavior.  Note that CVS HEAD is printing this case as
   
   	NestLoop
   		Seq Scan on a
   		Index Scan on b
   			Index Cond: x = $0
   
   which is definitely not very helpful.
   
   			regards, tom lane
   
   

4. Re: explain.c: why trace PlanState and Plan trees separately?

   Yeb Havinga <yebhavinga@gmail.com> — 2010-07-13T15:21:07Z

   Tom Lane wrote:
   > Yeb Havinga <yebhavinga@gmail.com> writes:
   >   
   >> Tom Lane wrote:
   >>     
   >>> The reason I'm on about this at the moment is that I think I see how to
   >>> get ruleutils to print PARAM_EXEC Params as the referenced expression
   >>> rather than $N ...
   >>>       
   >> Wouldn't this obfuscate the plan more than printing subplan arguments at 
   >> the call site?
   >>     
   >
   > It would if subplans could have more than one call site, but they can't.
   >
   > I do intend to force qualification of Vars that are printed as a result
   > of param expansion;
   >   
   Will the new referenced expression printing also be used when printing 
   subplans?
   
   If yes, I do not have to submit the latest version of a patch I made for 
   subplan argument printing (discussed earlier in this thread 
   http://archives.postgresql.org/pgsql-hackers/2010-02/msg01602.php)
   
   regards,
   Yeb Havinga
   
   
   

5. Re: explain.c: why trace PlanState and Plan trees separately?

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-07-13T18:14:25Z

   Yeb Havinga <yebhavinga@gmail.com> writes:
   > Will the new referenced expression printing also be used when printing 
   > subplans?
   
   > If yes, I do not have to submit the latest version of a patch I made for 
   > subplan argument printing (discussed earlier in this thread 
   > http://archives.postgresql.org/pgsql-hackers/2010-02/msg01602.php)
   
   Oh, I had forgotten that patch was still in progress.  I think it's
   unnecessary given what I'm fooling with.  The attached patch needs
   some more testing, but what I get with it is for example
   
   regression=# explain (verbose) select (select oid from pg_class a where
   regression(# a.oid = b.relfilenode) from pg_class b;
                                                  QUERY PLAN                                               
   --------------------------------------------------------------------------------------------------------
    Seq Scan on pg_catalog.pg_class b  (cost=0.00..5556.81 rows=669 width=4)
      Output: (SubPlan 1)
      SubPlan 1
        ->  Index Scan using pg_class_oid_index on pg_catalog.pg_class a  (cost=0.00..8.27 rows=1 width=4)
              Output: a.oid
              Index Cond: (a.oid = b.relfilenode)
   (6 rows)
   
   (this is the first example in the above-referenced thread).
   
   			regards, tom lane