pg.ddx.io pgsql-sql@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Richard Huxton <dev@archonet.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Rod Taylor <rbt@rbt.ca>
Cc: ow <oneway_111@yahoo.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: 7.4 - FK constraint performance
Date: Fri, 13 Feb 2004 07:22:17 +0000
Message-ID: <200402130722.17663.dev@archonet.com> (raw)
In-Reply-To: <27443.1076646336@sss.pgh.pa.us>
References: <20040213010341.95282.qmail@web60801.mail.yahoo.com>
<1076640825.10896.12.camel@jester>
<27443.1076646336@sss.pgh.pa.us>
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
view thread (29+ messages) latest in thread
Message-ID: <200402130722.17663.dev@archonet.com> Permalink: ../200402130722.17663.dev@archonet.com/ Also on: postgresql.org/message-id/200402130722.17663.dev@archonet.com ·
reply
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: dev@archonet.com, tgl@sss.pgh.pa.us, rbt@rbt.ca, oneway_111@yahoo.com Subject: Re: 7.4 - FK constraint performance In-Reply-To: <200402130722.17663.dev@archonet.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