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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>, 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: 2010-11-12 16:43:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Nov 12, 2010 at 4:15 AM, Cdric Villemain
> <cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote:
>>> I wondering if we could do something with a formula like 3 *
>>> amount_of_data_to_read / (3 * amount_of_data_to_read +
>>> effective_cache_size) = percentage NOT cached. That is, if we're
>>> reading an amount of data equal to effective_cache_size, we assume 25%
>>> caching, and plot a smooth curve through that point. In the examples
>>> above, we would assume that a 150MB read is 87% cached, a 1GB read is
>>> 50% cached, and a 3GB read is 25% cached.

>> But isn't it already the behavior of effective_cache_size usage ?

> No.

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.

> The ideal of trying to know what is actually in cache strikes me as an
> almost certain non-starter.

Agreed on that point.  Plan stability would go out the window.

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Kyriacos KyriacouDate: 2010-11-12 17:13:14
Subject: Re: MVCC performance issue
Previous:From: Kyriacos KyriacouDate: 2010-11-12 16:33:22
Subject: Re: MVCC performance issue

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