From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | |
Cc: | sqllist <pgsql-sql(at)postgresql(dot)org>, Jeff MacDonald <jeff(at)pgsql(dot)com> |
Subject: | Re: OID Perfomance - Object-Relational databases |
Date: | 2000-10-04 00:33:15 |
Message-ID: | 39DA7ACB.EA4D0B3E@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom,
> By and large I'd recommend using a serial column in preference to OIDs,
> though, for two reasons:
>
> 1. dump/restore is more practical that way (don't have to worry about
> saving/reloading OIDs).
>
> 2. counter overflow problems hit you only per-table, not
> per-installation.
Hmmm ... for some tables, switching to Serial would work. However, one
of the things I've done is add universal mod_data (modification stats)
and notes tables, which have to relate via OID because they relate to
5-7 different tables. To wit:
CREATE TABLE notes AS (
ref_OID OID,
staff_OID OID REFERENCES staff,
note_date DATE,
note_text TEXT
)
And the ref_oid relates to any of 5 different tables, thus allowing a
single table to hold notes on clients, candidates, bills, etc. Very
elegant, and using serials instead of the OID not possible.
SO I'm concerned about the problems you mentioned above. pg_dump has a
-o option; are there problems with this? And how liekly are counter
overflow problems?
Josh Berkus
--
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh(at)agliodbs(dot)com
and data management solutions (415) 436-9166
for law firms, small businesses fax 436-0137
and non-profit organizations. pager 338-4078
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fork | 2000-10-04 01:26:29 | Re: OID Perfomance - Object-Relational databases |
Previous Message | Peter Mount | 2000-10-03 23:56:55 | RE: Object features of pg |