Tom Lane escreveu:
Gregory Stark <st...@enterprisedb.com> writes:
Adriano Lange <adri...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
