Content-Type: text/plain;
  charset="iso-8859-1"
From: Richard Huxton <dev@archonet.com>
Organization: Archonet Ltd
To: <ries@jongert.nl>, <pgsql-sql@postgresql.org>
Subject: Re: Dublicates pairs in a table.
Date: Tue, 17 Sep 2002 11:07:33 +0100
User-Agent: KMail/1.4.1
References: <000201c25e14$921a9e10$6500000a@IT000>
In-Reply-To: <000201c25e14$921a9e10$6500000a@IT000>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200209171107.33845.dev@archonet.com>

On Tuesday 17 Sep 2002 7:36 am, Ries van Twisk wrote:
> Richard,
>
> do you suggest using a stored procedure to handle this? I do expect that
> the table will be large (for me large is a around 10000-20000 records, the
> table as more columns but I only need the restriction on c1 & c2) but I
> don=92t expect lots of inserts and deletes. Data entry will be done using=
 a
> regular user but of course a update needs to be done within a acceptable
> time so the user does not get annoyed.

I'd go with the UNIQUE INDEX. You're unlikely to be able to write code any=
=20
faster than the built-in indexing code. It's also simpler and easier for=20
someone else to see what's going on.

The only time the index will slow you down is on an insert/delete when the=
=20
index needs to be updated as well as the table. However, without the index=
=20
you'll need to scan the table to check for duplicates. For thousands of=20
records that can only be slower.

To put your mind at ease, I'd put together some test data and try it - noth=
ing=20
like seeing some real evidence.

HTH

- Richard Huxton