Robert Haas <robertmhaas@gmail.com> writes:
> On Sep 6, 2009, at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... But now that we have a plan for a less obviously broken costing
>> approach, maybe we should open the floodgates and allow
>> materialization
>> to be considered for any inner path that doesn't materialize itself
>> already
> Maybe. I think some experimentation will be required. We also have
> to be aware of effects on planning time; match_unsorted_outer() is,
> AIR, a significant part of the CPU cost of planning large join problems.
I've committed some changes pursuant to this discussion. It may be that
match_unsorted_outer gets a bit slower, but I'm not too worried about
that. My experience is that the code that tries different mergejoin
options eats way more cycles than the nestloop code does.
regards, tom lane