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: 20040213065530.M19832@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Responses

Browse pgsql-hackers by date

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

Browse pgsql-sql by date

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