"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> So, in the interim, Ben's trying to do it by hand: preorder the joins
> and demonstrate that the 'best' order is in fact the best. Then move on
> to looking into integrating this, if possible: part of the problem is
> recognizing the structure of the query, of course. Right now, the planner
> is getting in the way - although he can extract the needed timing info,
> he's wasting CPU cycles planning things that don't need it, limiting
> the number of cases he can try.
What's the basis for your assertion that it's "planning things that
don't need it"? Given a JOIN-constrained query I do not believe the
planner will look at any cases other than the intended join order.
> As mentioned before, there's currently no interface to feed in a Plan,
> so he's out of luck. Is there, programmatically, a way to do it?
> Serialize a plan tree to a file, and feed it in latter, purely for
> development purposes. How painful would that be? Should I send him in to
> see if he can implement one quickly, or are there dragons hiding in there?
He can do whatever he wants, as long as he has no illusions about
getting it accepted back into the sources ;-).
What would probably be more useful is to do some profiling to understand
why the planner is taking longer than he wants even with a
JOIN-constrained query. I should think this would be pretty quick.
regards, tom lane