Re: OID Perfomance - Object-Relational databases - Mailing list pgsql-sql

From Josh Berkus
Subject Re: OID Perfomance - Object-Relational databases
Date
Msg-id 39DA7ACB.EA4D0B3E@agliodbs.com
Whole thread Raw
In response to OID Perfomance - Object-Relational databases  (Josh Berkus <josh@agliodbs.com>)
Responses Re: OID Perfomance - Object-Relational databases
Re: OID Perfomance - Object-Relational databases
List 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
informationtechnology      josh@agliodbs.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


pgsql-sql by date:

Previous
From: Peter Mount
Date:
Subject: RE: Object features of pg
Next
From: Michael Fork
Date:
Subject: Re: OID Perfomance - Object-Relational databases