On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Stephen Frost <sfr...@snowman.net> writes: > > * Atri Sharma (atri.j...@gmail.com) wrote: > >> Agreed, but in some cases, we could possibly make some assumptions (if > >> there is no index, if a large fraction of table will be returned in > scan, > >> FunctionScan). > > > All neat ideas but how about we get something which works in the way > > being asked for before we start trying to optimize it..? Maybe I'm > > missing something, but getting all of this infrastructure into place and > > making sure things aren't done to the plan tree which shouldn't be (or > > done to all of them if necessary..) is enough that we should get that > > bit done first and then worry if there are ways we can further improve > > things.. > > Yeah; moreover, there's no evidence that hard-wiring such assumptions > would save anything. In the example of a FunctionScan, guess what: > there's only one Path for that relation anyway. > > That is precisely what I meant :) I guess I was being too over cautious and even trying to save the time spent in evaluating whatever paths we have and building new FunctionScan paths... > I think the right approach for now is to emulate the GEQO precedent as > closely as possible. Build all the single-relation Paths the same as > now, then do a join search over all the relations, then (if we've noticed > that some joins are potentially removable) do another join search over > just the nonremovable relations. > How about using geqo more liberally when replanning (decrease the number of relations in join before geqo is hit?) -- Regards, Atri *l'apprenant*
