| From: | Florent Guillaume <efgeor(at)noos(dot)fr> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: curval was Re: is PG able to handle a >500 GB Database? |
| Date: | 2001-01-21 14:39:49 |
| Message-ID: | 20010121153949.A4189@twin.efge.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> > On a different note. OID's are not guaranteed to be unique within a table?
>
> Not unless you put a unique index on its OID column. Of course, you
> won't actually see a conflict until you've been running your database
> long enough to wrap around the OID counter...
I think it would be a good thing to update the documentation, because
it's misleading at best :
oid
stands for the **unique** identifier of an instance which is added
by Postgres to all instances automatically. Oids **are not reused**
and are 32 bit quantities.
Bruce's book even starts a section with :
Every row in POSTGRESQL is assigned a **unique**, normally invisible
number called an object identification number (OID). When the software
is initialized with initdb, a counter is created and set to
approximately seventeen-thousand. The counter is used to **uniquely**
number every row. Although databases may be created and destroyed, the
counter continues to increase. It is used by all databases, so
identification numbers are always **unique**. **No two rows in any table or
in any database will ever have the same object ID.**
(emphasis mine)
Florent
--
<florent(dot)guillaume(at)mail(dot)com>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | leif | 2001-01-21 14:44:05 | ACS Web Server & PostgreSQL |
| Previous Message | Alexander Jerusalem | 2001-01-21 12:18:54 | postgres memory management |