<div dir="ltr">Thank you for your reply Tom. Then a) what are exactly stored in the pathlist of top level rel? Paths
worthconsidering? b) I have been struggling to come up with a way to print the Path struct. If I can print a path the
waylike "A hash join (B nested loop join C)", that would be great. You mentioned people have printed "something" about
eachpath, can you please give me a hint of what's that and how to achieve that?</div><div class="gmail_extra"><br /><br
/><divclass="gmail_quote">On Thu, Nov 14, 2013 at 12:01 PM, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us"target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Zhan Li <<a
href="mailto:zhanli89@gmail.com">zhanli89@gmail.com</a>>writes:<br /> > When searching all the possible paths of
executinga query, the optimizer<br /> > finds and saves the cheapest paths for the top level rel. I'd like to
check<br/> > out all the paths the optimizer has ever considered, which I believe, are<br /> > stored in the
pathlistof the top level rel.<br /><br /></div>No, most of them have been thrown away long before that. See
add_path.<br/> Also realize that in a large join problem, a lot of potential plans never<br /> get explicitly
considered,because the input paths get pruned before we<br /> get to considering the join rel at all. (If this were
notso, planning<br /> would take too long.)<br /><br /> People have experimented with having add_path print something
abouteach<br /> path that's fed to it, but the output tends to be voluminous and not all<br /> that useful.<br /><br />
regards, tom lane<br /></blockquote></div><br /></div>