X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 4DCBED1DA69 for ; Sun, 15 Feb 2004 16:42:00 +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 22349-07 for ; Sun, 15 Feb 2004 12:41:58 -0400 (AST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 2F84DD1D8F3 for ; Sun, 15 Feb 2004 12:41:58 -0400 (AST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 4F41C35657; Sun, 15 Feb 2004 08:41:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 4DBB83564B; Sun, 15 Feb 2004 08:41:57 -0800 (PST) Date: Sun, 15 Feb 2004 08:41:57 -0800 (PST) From: Stephan Szabo To: Tom Lane Cc: pgsql-hackers@postgresql.org Subject: Re: [SQL] 7.4 - FK constraint performance In-Reply-To: <20040213080628.E21355@megazone.bigpanda.com> Message-ID: <20040215083314.B85170@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> <20040213065530.M19832@megazone.bigpanda.com> <2455.1076686047@sss.pgh.pa.us> <20040213073852.K20792@megazone.bigpanda.com> <2662.1076687804@sss.pgh.pa.us> <20040213080628.E21355@megazone.bigpanda.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/566 X-Sequence-Number: 50155 On Fri, 13 Feb 2004, Stephan Szabo wrote: > > On Fri, 13 Feb 2004, Tom Lane wrote: > > > Stephan Szabo writes: > > > On Fri, 13 Feb 2004, Tom Lane wrote: > > >> I was looking at that last night. It seems like we could add a LIMIT at > > >> least in some contexts. In the case at hand, we're just going to error > > >> out immediately if we find a matching row, and so there's no need for > > >> FOR UPDATE, is there? > > > > > I think there still is, because a not yet committed transaction could have > > > deleted them all in which case I think the correct behavior is to wait and > > > if that transaction commits allow the action and if it rolls back to > > > error. > > > > Good point. Okay, we can't put in a LIMIT. But we could still hack the > > planner to prefer a fast-start plan by passing an out-of-band tuple > > fraction, for those RI plans where it's appropriate. That would not > > affect correctness. > > Right, I can try to look through the stuff you pointed at in the previous > message over the weekend. It looks to me that we could make this available to SPI fairly simply by taking the current version of the following four routines: planner, pg_plan_query, _SPI_execute and SPI_prepare, renaming them and giving them a planning tuple fraction as a parameter, change references to the other routines to the new names and then making four new functions with the current names that call the renamed versions. In all the cases other than planner I think we can have the new version pass 0.0 and in the case of planner either 0.1 or 0.0 based on the isCursor parameter.