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