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

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 (view raw or flat)
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

pgsql-performance by date

Next:From: Kyriacos KyriacouDate: 2010-11-12 16:33:22
Subject: Re: MVCC performance issue
Previous:From: Tom LaneDate: 2010-11-12 16:28:53
Subject: Re: MVCC performance issue

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