Skip site navigation (1) Skip section navigation (2)

Re: 7.4 - FK constraint performance

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rod Taylor <rbt(at)rbt(dot)ca>, ow <oneway_111(at)yahoo(dot)com>,pgsql-sql(at)postgresql(dot)org
Subject: Re: 7.4 - FK constraint performance
Date: 2004-02-13 15:02:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-sql
On Thu, 12 Feb 2004, Tom Lane wrote:

> Rod Taylor <rbt(at)rbt(dot)ca> 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?

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-02-13 15:27:27
Subject: Re: 7.4 - FK constraint performance
Previous:From: Tom LaneDate: 2004-02-13 14:50:08
Subject: Re: Transaction aborts on syntax error.

pgsql-sql by date

Next:From: Tom LaneDate: 2004-02-13 15:15:31
Subject: Re: column alias and group by/having/order
Previous:From: Tom LaneDate: 2004-02-13 15:02:39
Subject: Re: arrays and polygons

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group