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

From Cédric Villemain
Subject Re: anti-join chosen even when slower than old plan
Date
Msg-id AANLkTikjrzkU2ADnEB7qw=grn8OFpgc-R=VsiSz_zW1J@mail.gmail.com
Whole thread Raw
In response to Re: anti-join chosen even when slower than old plan  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-performance
2011/1/20 Robert Haas <robertmhaas@gmail.com>:
> 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"?

or    "Estimate caching effect in the query context instead of per
object" (the point above)
and "Improve the estimate of the caching effects" (more or less M-L
review, fine control of cache estimate)

?

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



--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

pgsql-performance by date:

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