Skip site navigation (1) Skip section navigation (2)

Re: anti-join chosen even when slower than old plan

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: anti-join chosen even when slower than old plan
Date: 2011-01-20 16:16:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
2011/1/20 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Jan 20, 2011 at 4:17 AM, Cédric Villemain
> <cedric(dot)villemain(dot)debian(at)gmail(dot)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:
> The Enterprise PostgreSQL Company

Cédric Villemain               2ndQuadrant     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-performance by date

Next:From: Cédric VillemainDate: 2011-01-20 16:36:05
Subject: Re: anti-join chosen even when slower than old plan
Previous:From: Scott MarloweDate: 2011-01-20 15:43:43
Subject: Re: Migrating to Postgresql and new hardware

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group