Re: Ideas of "printing out" the alternative paths
От
Zhan Li
Тема
Re: Ideas of "printing out" the alternative paths
Дата
Msg-id
CANp-Bfa=L-JrR1oZLZkjbW61Pj8OoPN_SfU8DgbNAwzZOpFCFg@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Ideas of "printing out" the alternative paths Zhan Li <zhanli89@gmail.com>
Re: Ideas of "printing out" the alternative paths Tom Lane <tgl@sss.pgh.pa.us>
Re: Ideas of "printing out" the alternative paths Zhan Li <zhanli89@gmail.com>
Re: Ideas of "printing out" the alternative paths Tom Lane <tgl@sss.pgh.pa.us>
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@sss.pgh.pa.us> wrote:
Zhan Li <zhanli89@gmail.com> writes:No, most of them have been thrown away long before that. See add_path.
> 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.
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
В списке pgsql-hackers по дате отправления
От: Fujii Masao
Дата:
От: Heikki Linnakangas
Дата: