Re: anti-join chosen even when slower than old plan - Mailing list pgsql-performance

From Robert Haas
Subject Re: anti-join chosen even when slower than old plan
Date
Msg-id AANLkTi=OYC2dN1SkaSY5AEyOVd4Zu-YPTgW-YKV=+xsj@mail.gmail.com
Whole thread Raw
In response to Re: anti-join chosen even when slower than old plan  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Responses Re: anti-join chosen even when slower than old plan  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Re: anti-join chosen even when slower than old plan  (Bruce Momjian <bruce@momjian.us>)
List pgsql-performance
On Thu, Jan 20, 2011 at 4:17 AM, Cédric Villemain
<cedric.villemain.debian@gmail.com> wrote:
>>> I think his point is that we already have a proven formula
>>> (Mackert-Lohmann) and shouldn't be inventing a new one out of thin air.
>>> The problem is to figure out what numbers to apply the M-L formula to.
>>>
>>> I've been thinking that we ought to try to use it in the context of the
>>> query as a whole rather than for individual table scans; the current
>>> usage already has some of that flavor but we haven't taken it to the
>>> logical conclusion.
>>
>> Is there a TODO here?
>
> it looks like, yes.

"Modify the planner to better estimate caching effects"?

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

pgsql-performance by date:

Previous
From: Cédric Villemain
Date:
Subject: Re: anti-join chosen even when slower than old plan
Next
From: Andy Colson
Date:
Subject: Re: Migrating to Postgresql and new hardware