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 AANLkTikt06NuAxmbvFbQv62Dz6zDgU6PJhj8YMUjmxZi@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Fri, Nov 12, 2010 at 4:15 AM, Cédric Villemain
<cedric.villemain.debian@gmail.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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: MVCC performance issue
Next
From: "Kyriacos Kyriacou"
Date:
Subject: Re: MVCC performance issue