Re: WIP patch for parameterized inner paths

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 26, 2012 at 2:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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