From: | Adriano Lange <adriano(at)c3sl(dot)ufpr(dot)br> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: graph representation of data structures in optimizer |
Date: | 2009-02-19 00:55:54 |
Message-ID: | 499CAE1A.4020504@c3sl.ufpr.br |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane escreveu:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Adriano Lange <adriano(at)c3sl(dot)ufpr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Adriano Lange | 2009-02-19 01:12:53 | Re: graph representation of data structures in optimizer |
Previous Message | Tom Lane | 2009-02-18 23:37:08 | Re: The science of optimization in practical terms? |