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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
