From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [SQL] 7.4 - FK constraint performance
Date: Sun, 15 Feb 2004 08:41:57 -0800 (PST)
Message-ID: <20040215083314.B85170@megazone.bigpanda.com> (raw)
In-Reply-To: <20040213080628.E21355@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>
On Fri, 13 Feb 2004, Stephan Szabo wrote:
>
> On Fri, 13 Feb 2004, Tom Lane wrote:
>
> > Stephan Szabo <sszabo@megazone.bigpanda.com> 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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: sszabo@megazone.bigpanda.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: [SQL] 7.4 - FK constraint performance
In-Reply-To: <20040215083314.B85170@megazone.bigpanda.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox