Re: graph representation of data structures in optimizer

Tom Lane escreveu:
> Gregory Stark <stark@enterprisedb.com> writes:
>> Adriano Lange <adriano@c3sl.ufpr.br> writes:
>>> I've changed the debug functions of allpaths.c to make a graphviz-like output
>>> of RelOptInfo structure.
> 
>> However I have to say this graph you've generated is amazingly hard to
>> decipher :) It took me a while to even figure out what information it was
>> presenting.
> 
>> Worse, it's not useful unless you add a lot more information to it such as
>> what relations are actually being scanned or joined at each path which is
>> going to make it a hell of a lot harder to read.
> 
> Labeling the bottom-level scan paths with their relations would help a
> lot.  The label at the top level isn't real helpful.
> 
> But really I think the problem with this approach is that the
> information density is too low --- imagine what it would look like in a
> six-or-more-way join.  I don't think the graphical approach is helpful
> at all here.

Certainly. That example had only three relations. Six relations in a 
RelOptInfo will make a big graph and too hard to understand.

So, I will think about this for a while. A interesting thing for me is 
to identify the in-degree pointers of each structure.

> Also, showing the final Path data structure has the problem that a lot
> of the information someone might want is already gone, because we throw
> away Paths that are determined to be dominated by other paths.  The
> question someone usually wants answered is "was a path of this structure
> considered at all, and if so what was the estimated cost?".  In a large
> fraction of cases, that's not answerable from the paths that remain at
> the end of the search.  I think some sort of on-the-fly tracing of all
> add_path calls might be a more useful approach.
> 
>             regards, tom lane

Humm. This temporal approach may be dificult to represent in this 
graphical mode. I guess that the text-like pretty_format_node_dump() 
representation and diff are yet more usefull for this.

--
Adriano Lange
C3SL/UFPR - www.c3sl.ufpr.br