Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 8B37F1337BA2 for ; Thu, 11 Nov 2010 15:17:08 -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 01943-06 for ; Thu, 11 Nov 2010 19:17:01 +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 3FCFB1337B8D for ; Thu, 11 Nov 2010 15:17:01 -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 oABJH0dM019476; Thu, 11 Nov 2010 14:17:00 -0500 (EST) To: Robert Haas cc: Kevin Grittner , Mladen Gogala , "pgsql-performance@postgresql.org" Subject: Re: anti-join chosen even when slower than old plan In-reply-to: References: <4CD9663502000025000374B1@gw.wicourts.gov> <20961.1289347680@sss.pgh.pa.us> <4CDA62C60200002500037512@gw.wicourts.gov> <4CDACBBF020000250003755B@gw.wicourts.gov> <4CDB7BAA.7020506@vmsinfo.com> <4CDBB0A40200002500037571@gw.wicourts.gov> <18450.1289499783@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 11 Nov 2010 14:02:14 -0500" Date: Thu, 11 Nov 2010 14:17:00 -0500 Message-ID: <19475.1289503020@sss.pgh.pa.us> From: Tom Lane 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/163 X-Sequence-Number: 41187 Robert Haas writes: > On Thu, Nov 11, 2010 at 1:23 PM, Tom Lane wrote: >> I do think that something based around a settable-per-table caching >> percentage might be a reasonable way to proceed.  But the devil is in >> the details, and we don't have those yet. > I think one of the larger devils in the details is deciding how to > estimate the assumed caching percentage when the user hasn't specified > one. I was imagining something very similar to the handling of seq_page_cost, ie, there's a GUC controlling the system-wide default and then you can override that per-table. But the real question is whether per-table is a useful granularity to control it at. See my later message. regards, tom lane