What I want to count is the number of plans that have been considered cheapest_path. Since if a path is considered to be a cheapest_path, the postgres optimizer need to spent time on comparison. I think this is what I want.
On Sat, Oct 03, 2009 at 04:20:59PM +1000, ????????? wrote: > Since I also need to consider gego, is this the best way to do it?
I think you need to be clearer about what you're trying to count. Consider a nestjoin plan where:
- For the inner side it considers 7 paths and throws away 4. - For the outer side it considers 6 paths and throws away 2.
Do you want the number 3*4=12 or 7*6=42? Or something in between (what if in addition to a nestjoin plan otther possibilities are possible).
As you can see, you can't talk about complete plans because they don't exist until right at the end, until then it's just considering how to combine different paths in sensible ways.
Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
