Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 107B21337C5F
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 12 Nov 2010 12:46:16 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 13830-01-10
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 12 Nov 2010 16:46:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 738C71337C45
	for <pgsql-performance@postgresql.org>;
	Fri, 12 Nov 2010 12:43:06 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id oACGh5tV011746;
	Fri, 12 Nov 2010 11:43:05 -0500 (EST)
To: Robert Haas <robertmhaas@gmail.com>
cc: =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric.villemain.debian@gmail.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Mladen Gogala <mladen.gogala@vmsinfo.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: anti-join chosen even when slower than old plan 
In-reply-to: <AANLkTikt06NuAxmbvFbQv62Dz6zDgU6PJhj8YMUjmxZi@mail.gmail.com> 
References: <4CD9663502000025000374B1@gw.wicourts.gov>
	<20961.1289347680@sss.pgh.pa.us>
	<4CDA62C60200002500037512@gw.wicourts.gov>
	<AANLkTi=eNXKEBo5dXJDd4+aHhfmkibH++fqjj12+DA3o@mail.gmail.com>
	<4CDACBBF020000250003755B@gw.wicourts.gov>
	<4CDB7BAA.7020506@vmsinfo.com>
	<4CDBB0A40200002500037571@gw.wicourts.gov>
	<AANLkTi=dzhRTTNm1LkyNCAC5+PWbp1jWtKFh4T1Bu4nj@mail.gmail.com>
	<18450.1289499783@sss.pgh.pa.us> <19088.1289501929@sss.pgh.pa.us>
	<AANLkTi=dnDwLEyxienHs7ZGP1k18YQzaQMPY7KP-hjMT@mail.gmail.com>
	<19796.1289504156@sss.pgh.pa.us>
	<AANLkTinNTG_kR_WiRWqJdgTe18Ghdxj6bmLR3OU70oqN@mail.gmail.com>
	<AANLkTimRqw+vd=83=RW3VbX8U_4fVJDpJZfMxa6uLvs3@mail.gmail.com>
	<AANLkTikt06NuAxmbvFbQv62Dz6zDgU6PJhj8YMUjmxZi@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 12 Nov 2010 11:30:24 -0500"
Date: Fri, 12 Nov 2010 11:43:05 -0500
Message-ID: <11745.1289580185@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201011/205
X-Sequence-Number: 41229

Robert Haas <robertmhaas@gmail.com> writes:
> 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.

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