Re: CHECK constraints and optimizations

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Edmund Dengler <edmundd(at)eSentire(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: CHECK constraints and optimizations
Date: 2004-05-06 15:29:42
Message-ID: Pine.LNX.4.33.0405060924510.4905-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 5 May 2004, Edmund Dengler wrote:

> Greetings!
>
> Just trying some tests out, and wanted to know about some optimizations.
> If I do a CHECK constraint on a table, is this used to optimize a SELECT
> or does Postgresql rely mostly on normal index search?

I think the only kind of constraint that incidentally improves performance
is a unique constraint, which creates a unique index.

A check constraint is run on a record when it is changed to make sure it
still meets the requirements of the constraint. There is no seperate file
that says "this row meets the constraint". Deferred constraints mean the
check is to be done at the commit time of the transaction.

Note that unique constraints are not necessarily deferrable due to issues
caused by using an immediate acting unique index. I don't think this is
easily fixable either.

So, a check constraint is of no use during a read from the table, and
is a performance penalty when writing to it.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ed L. 2004-05-06 16:40:18 Re: select for update & lock contention
Previous Message Crercio O. Silva 2004-05-06 15:17:58 New DBManager 2.3.0 is Released