On Sat, Sep 1, 2012 at 06:23:59PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, May 22, 2012 at 1:50 AM, Tom Lane wrote:
> >> Currently, the planner keeps paths that appear to win on the grounds of
> >> either cheapest startup cost or cheapest total cost. It suddenly struck
> >> me t
Robert Haas writes:
> On Tue, May 22, 2012 at 1:50 AM, Tom Lane wrote:
>> Currently, the planner keeps paths that appear to win on the grounds of
>> either cheapest startup cost or cheapest total cost. It suddenly struck
>> me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor
>
On Tue, May 22, 2012 at 08:29:48AM -0400, Robert Haas wrote:
> On Tue, May 22, 2012 at 1:50 AM, Tom Lane wrote:
> > Currently, the planner keeps paths that appear to win on the grounds of
> > either cheapest startup cost or cheapest total cost. It suddenly struck
> > me that in many simple cases
On Tue, May 22, 2012 at 1:50 AM, Tom Lane wrote:
> Currently, the planner keeps paths that appear to win on the grounds of
> either cheapest startup cost or cheapest total cost. It suddenly struck
> me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor
> fast-start preference, et
On 22 May 2012 12:12, PostgreSQL - Hans-Jürgen Schönig
wrote:
>
> On May 22, 2012, at 9:57 AM, Simon Riggs wrote:
>
>> On 22 May 2012 06:50, Tom Lane wrote:
>>
>>> Currently, the planner keeps paths that appear to win on the grounds of
>>> either cheapest startup cost or cheapest total cost. It
On May 22, 2012, at 9:57 AM, Simon Riggs wrote:
> On 22 May 2012 06:50, Tom Lane wrote:
>
>> Currently, the planner keeps paths that appear to win on the grounds of
>> either cheapest startup cost or cheapest total cost. It suddenly struck
>> me that in many simple cases (viz, those with no LI
On 22 May 2012 06:50, Tom Lane wrote:
> Currently, the planner keeps paths that appear to win on the grounds of
> either cheapest startup cost or cheapest total cost. It suddenly struck
> me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor
> fast-start preference, etc) we coul
Currently, the planner keeps paths that appear to win on the grounds of
either cheapest startup cost or cheapest total cost. It suddenly struck
me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor
fast-start preference, etc) we could know a-priori that cheapest startup
cost is no
