From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | John Jawed <johnjawed(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Difference between UNIQUE constraint vs index |
Date: | 2007-02-28 05:55:16 |
Message-ID: | 20070228055516.GF71555@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adding -general back in.
On Tue, Feb 27, 2007 at 07:19:15PM -0600, John Jawed wrote:
> This is more or less correct, I was looking for performance gains on
> the [possible] differences during DML and DDL.
>
> If Jim is correct, is there a particular reason that PostgreSQL does
> not behave like other RDBMs without a SET ALL DEFERRED? Or is this a
> discussion best left for -HACKERS?
Well, currently only FK constraints support deferred. And IIRC it's not
generally a performance gain, anyway.
What I was trying to say is that if you're running a query (generally a
SELECT) with certain conditions, the planner can make use of the
knowledge that a column or set of columns is guaranteed to be unique.
PostgreSQL currently can't do that.
> John
>
> On 2/27/07, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
> >On Tue, Feb 27, 2007 at 06:43:51PM -0600, John Jawed wrote:
> >> Is there any difference as far as when the "uniqueness" of values is
> >> checked in DML between a unique index vs a unique constraint? Or is
> >> the only difference syntax between unique indices and constraints in
> >> PostgreSQL?
> >
> >Syntax only, AFAIK. I prefer using constraints if I actually want to
> >constrain the data; it makes it clear that it's a restriction.
> >
> >In some databases if you know that an index just happens to be unique
> >you might gain some query performance by defining the index as unique,
> >but I don't think the PostgreSQL planner is that smart. There can also
> >be some additional overhead involved with a unique index (vs
> >non-unique), such as when two backends try and add the same key at the
> >same time (one of them will have to block).
> >--
> >Jim Nasby jim(at)nasby(dot)net
> >EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
> >
>
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Ang Chin Han | 2007-02-28 06:10:30 | Re: How to Kill IDLE users |
Previous Message | Kris Jurka | 2007-02-28 05:42:35 | Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?) |