Re: Multi-pass planner

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Greg Stark <stark(at)mit(dot)edu>, decibel <decibel(at)decibel(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Multi-pass planner
Date: 2013-04-04 20:28:57
Message-ID: CA+TgmoYLpVpHVS3pkiKQYn+v=MKA+m0z9KZVtGSf70xGGD+D=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 4, 2013 at 2:53 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> for estimate_worstcase_fraction. So, when computing the cost of a
>> path, we'd compute our current expected-case estimate, and also a
>> worst-case estimate, and then compute the final cost as:
>
> There also was the idea for the executor to be able to handle alternate
> plans and some heuristic to determine that the actual cost of running a
> plan is much higher than what's been estimated, so much so as to switch
> to starting from scratch with the other plan instead.

Yeah. The thing is, if the plan has any side effects, that's not
really an option. And even if it doesn't, it may throw away a lot of
work. One thing we could do is switch from a unparameterized nested
loop to a hash join if the outer side turns out to be much larger than
expected, but that's only going to benefit a pretty narrow set of use
cases. Which is why I think a planner-based approach is probably more
promising.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-04-04 20:29:59 Re: Hash Join cost estimates
Previous Message Stephen Frost 2013-04-04 20:16:12 Re: Hash Join cost estimates