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

Re: Clarification, please

From: Richard Broersma <richard(dot)broersma(at)gmail(dot)com>
To: Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Clarification, please
Date: 2010-12-01 16:57:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Wed, Dec 1, 2010 at 8:46 AM, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> wrote:

> PostgreSQL 9.0, however, creates a unique index:
>   scott=# create table test1
>   scott-# (col1 integer,
>   scott(#  constraint test1_pk primary key(col1) deferrable);
>   NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
>   "test1_pk" for table "test1"
>   Time: 67.263 ms
>   scott=# select indexdef from pg_indexes where indexname='test1_pk';
>                            indexdef
> ----------------------------------------------------------
>    CREATE UNIQUE INDEX test1_pk ON test1 USING btree (col1)
>   (1 row)
> When the constraint is deferred in the transaction block, however, it
> tolerates duplicate values until the end of transaction:
>   scott=# begin;                               BEGIN
>   Time: 0.201 ms
>   scott=# set constraints test1_pk  deferred;
>   Time: 0.651 ms
>   scott=# insert into test1 values(1);
>   INSERT 0 1
>   Time: 1.223 ms
>   scott=# insert into test1 values(1);
>   INSERT 0 1
>   Time: 0.390 ms
>   scott=# rollback;
>   Time: 0.254 ms
>   scott=#
> No errors here. How is it possible to insert the same value twice into a
> UNIQUE index? What's going on here?

    This controls whether the constraint can be deferred. A constraint
that is not deferrable will be checked immediately after every
command. Checking of constraints that are deferrable can be postponed
until the end of the transaction (using the SET CONSTRAINTS command).
NOT DEFERRABLE is the default. Currently, only UNIQUE, PRIMARY KEY,
EXCLUDE, and REFERENCES (foreign key) constraints accept this clause.
NOT NULL and CHECK constraints are not deferrable.

It looks like the check isn't preformed until COMMIT.

Richard Broersma Jr.

In response to


pgsql-performance by date

Next:From: Mario SplivaloDate: 2010-12-01 17:00:26
Subject: Re: SELECT INTO large FKyed table is slow
Previous:From: Mladen GogalaDate: 2010-12-01 16:46:27
Subject: Clarification, please

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