X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id DFED8D1D2F7 for ; Fri, 13 Feb 2004 15:02:49 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 09022-09 for ; Fri, 13 Feb 2004 11:02:51 -0400 (AST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 8ABFCD1D298 for ; Fri, 13 Feb 2004 11:02:47 -0400 (AST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 10622358CC; Fri, 13 Feb 2004 07:02:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 0ED7B358B9; Fri, 13 Feb 2004 07:02:51 -0800 (PST) Date: Fri, 13 Feb 2004 07:02:51 -0800 (PST) From: Stephan Szabo To: Tom Lane Cc: Rod Taylor , ow , pgsql-sql@postgresql.org Subject: Re: 7.4 - FK constraint performance In-Reply-To: <27443.1076646336@sss.pgh.pa.us> Message-ID: <20040213065530.M19832@megazone.bigpanda.com> References: <20040213010341.95282.qmail@web60801.mail.yahoo.com> <25808.1076634636@sss.pgh.pa.us> <1076640825.10896.12.camel@jester> <27443.1076646336@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/147 X-Sequence-Number: 16838 On Thu, 12 Feb 2004, Tom Lane wrote: > Rod Taylor writes: > > Statistics say there are 10 values. Statistics list the 10 most common > > values (all of them). Given this, would it not be reasonable to assume > > that 239 is a recent addition (if there at all) to the table and not > > very common? > > We don't know that it's 239 when we make the plan. In order to know > that, we'd have to abandon caching of RI check query plans and re-plan > for each row. That strikes me as inevitably a losing proposition. One thing is that IIRC we're going to ask for only one row when we do the SPI_execp_current. However, unless I misremember, the behavior of for update and limit means that saying limit 1 is potentially unsafe (if you block on a row that goes away). Is there anyway for us to let the planner know this?