Re: OID Perfomance - Object-Relational databases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
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-03 19:10:45
Message-ID: 29675.970600245@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> 1. Is there a performance loss on searches and joins when I use the OID
> as a liniking field as opposed to a SERIAL column?

> 2. Can I define my own index on the OIDs of a table?

There is absolutely no magic about OIDs, except that the system insists
on adding one to every row you store. In particular, they don't offer
any magic fast way to find a tuple. If you want fast retrieval by OID
in a particular table then you *MUST* define an index on the OID column,
like so:

CREATE TABLE foo ( ... );

CREATE INDEX foo_oid_index ON foo (oid);

The performance of an index on OID will be indistinguishable from the
performance of an index on an int4 or serial column.

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.

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Mads Jensen 2000-10-03 20:20:48 Possibly to get off the list?
Previous Message Tom Lane 2000-10-03 19:03:41 Re: Something I'd like to try...