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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
Cc: 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: 2010-11-12 16:30:24
Message-ID: AANLkTikt06NuAxmbvFbQv62Dz6zDgU6PJhj8YMUjmxZi@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Nov 12, 2010 at 4:15 AM, Cédric 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.

The ideal of trying to know what is actually in cache strikes me as an
almost certain non-starter. It can change very quickly, even as a
result of the query you're actually running. And getting the
information we'd need in order to do it that way would be very
expensive, when it can be done at all.

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kyriacos Kyriacou 2010-11-12 16:33:22 Re: MVCC performance issue
Previous Message Tom Lane 2010-11-12 16:28:53 Re: MVCC performance issue