On Tue, May 26, 2009 at 3:04 PM, Greg Stark <greg.stark@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
