On Tue, May 26, 2009 at 3:04 PM, Greg Stark <greg.st...@enterprisedb.com> wrote: > (sorry for top posting - stupid apple) > > So the real elephant in the room is that the existing explain code is not > really designed to be extensible, configurable, or to be printed in > different formats. > > The current code is basically just gobs of text printed by different > routines all over the code base. There are no data structures which
All over the code base? It looks to me like most of it is in explain.c, specifically explain_outNode(). (On an unrelated point, it's difficult to imagine why someone thought that was a good way of capitalizing & punctuating that function name.) > represent what explain prints. The closest thing is the instrumentation > objects which obtain the timing and counts but not the planner expectations > or any associated data. > > If we're going to support multiple output formats or options to turn off and > on sections I think we need to build a data structure independent of the > format, have code to include or exclude stats as requested and then pass > that to the requested formatter. That sounds about right to me. I think that representation can be pretty thin, though, maybe just a big struct with all the attributes that are applicable to any node type and pointers to its left and right children. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
