Re: 7.4 - FK constraint performance - Mailing list pgsql-sql

From Richard Huxton
Subject Re: 7.4 - FK constraint performance
Date
Msg-id 200402130722.17663.dev@archonet.com
Whole thread Raw
In response to Re: 7.4 - FK constraint performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 7.4 - FK constraint performance  (Rod Taylor <rbt@rbt.ca>)
Re: 7.4 - FK constraint performance  (Rod Taylor <rbt@rbt.ca>)
List pgsql-sql
On Friday 13 February 2004 04:25, Tom Lane wrote:
> Rod Taylor <rbt@rbt.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.

In this precise example, could you not: 1. Check index for value 2. If found, seq-scan

Of course that's only going to be a sensible thing to do if you're expecting 
one of two results: 1. Value not there 2. Lengthy seq-scan if it is there
--  Richard Huxton Archonet Ltd


pgsql-sql by date:

Previous
From: "Kumar"
Date:
Subject: Re: How to avoid nulls while writing string for dynamic query
Next
From: Tomasz Myrta
Date:
Subject: Re: How to avoid nulls while writing string for dynamic query