Re: Ideas of "printing out" the alternative paths

Thank you for your reply Tom. Then a) what are exactly stored in the
pathlist of top level rel? Paths worth considering? b) I have been
struggling to come up with a way to print the Path struct. If I can print a
path the way like "A hash join (B nested loop join C)", that would be
great. You mentioned people have printed "something" about each path, can
you please give me a hint of what's that and how to achieve that?

On Thu, Nov 14, 2013 at 12:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Zhan Li <zhanli89(at)gmail(dot)com> writes:
> > When searching all the possible paths of executing a query, the optimizer
> > finds and saves the cheapest paths for the top level rel. I'd like to
> check
> > out all the paths the optimizer has ever considered, which I believe, are
> > stored in the pathlist of the top level rel.
>
> No, most of them have been thrown away long before that. See add_path.
> Also realize that in a large join problem, a lot of potential plans never
> get explicitly considered, because the input paths get pruned before we
> get to considering the join rel at all. (If this were not so, planning
> would take too long.)
>
> People have experimented with having add_path print something about each
> path that's fed to it, but the output tends to be voluminous and not all
> that useful.
>
> regards, tom lane
>