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 <t...@sss.pgh.pa.us> wrote: > Zhan Li <zhanl...@gmail.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 >
