I quote from the PG Docs:
PRIMARY KEY (column constraint)
PRIMARY KEY ( column_name [, ... ] ) (table constraint)
The primary key constraint specifies that a column or columns of a table may
contain only unique (non-duplicate), non-NULL values. Technically, PRIMARY
KEY is merely a combination of UNIQUE and NOT NULL, but identifying a set of
columns as primary key also provides meta-data about the design of the
schema, as a primary key implies that other tables may rely on this set of
columns as a unique identifier for rows.
Only one primary key can be specified for a table, whether as a column
constraint or a table constraint.
The primary key constraint should name a set of columns that is different
from other sets of columns named by any unique constraint defined for the
same table.
My question is this, I want to create a very large table, 1M records or
more. However, as I was reading some of the recent posts, namely:
From: Antonios Christofides <anthony ( at ) itia ( dot ) ntua ( dot ) gr>
To: pgsql-novice ( at ) postgresql ( dot ) org
Subject: Surrogate vs natural keys (Was: Almost relational PostgreSQL (was:
one-to-one))
Date: Tue, 4 Nov 2003 20:51:25 +0200
The table I am creating would be based on a X,Y point. We have serious
doubts on what this would do to the performance of the system we are
developing. I am assuming, that a table can have a primary key consisting
of 2 fields, which together would be unique to the entire table. Would
indexing this table be the nightmare we think it would be? Has anyone seen
anything remotely similar out there with 1M+ rows?
Thanks.
Farid