Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 26, 2012 at 2:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I've implemented this idea, recast a bit to prevent generating a
>> parameterized join path in the first place unless it depends on a
>> parameter from a relation for which there's a join ordering constraint
>> still outstanding. It seems to get us to where the planning time
>> penalty is only about 10%, which frankly is probably less than sampling
>> error considering the small set of test cases I'm looking at.
> Awesome. If you can post the updated patch, I'll poke at it a little
> more and see if anything jumps out at me, but that sounds promising.
Attached is what I have right now. When you suggested the above,
I was in the middle of recasting the join cost functions along the lines
I suggested previously (ie, second phase re-uses work from the first),
so in the attached, cost_nestloop is done "right" but merge and hash
are still using duplicative coding. We might shave another percent or
two once that work is complete, but I don't expect it to change the
behavior otherwise.
This is against git head from Tuesday, though I think none of the more
recent commits touched the planner.
regards, tom lane
