Re: match_unsorted_outer() vs. cost_nestloop()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: match_unsorted_outer() vs. cost_nestloop()
Date: 2009-09-12 22:14:39
Message-ID: 19544.1252793679@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sep 6, 2009, at 10:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Otto 2009-09-12 22:19:57 Re: drop tablespace error: invalid argument
Previous Message Peter Eisentraut 2009-09-12 22:13:12 pgsql: Add Unicode support in PL/Python PL/Python now accepts Unicode