Jayadevan M wrote:
Hi,
> The primary question that needs to be asked is what do you want to
do with them?
> It is not so much a performance issue as an admin issue. OIDs where
created for
> Postgres internal system use and leaked out to user space. As a
result they
> have some shortcomings as detailed in the above article. Given that
sequences
> are available as number generators, it was decided to
encourage/force OIDs to
> be for internal system use only. That decision is set and using OIDs
on user
> tables is setting yourself for future problems.
I am an Oracle guy who is learning PostgreSQL. oid sounded a lot like
rowid in Oracle. In Oracle, access by rowid is expected to be the
fastest way of accessing a record, faster than even an index access
followed by table access using the primary key. That was why I have
this doubt about usage of oid being deprecated. Even if we use a
sequence as PK (which is there in Oracle too), it is not as fast as
access by rowid (I don't know if this applies to PostgreSQL's oid
too). This is important when we use a cursors in an Oracle procedure
(function in PostgreSQL) and loop through it and update specific
records, when some conditions are met. Of course, that approach has
its drawbacks -as in the case when row movement is enabled some
maintenance activity moves the row to another location. Another
scenario is when we want to delete duplicate records in a table.
well, postgres' OID's were never a direct row address of any sort. as
the previous poster said, OID's were an internal identifier, and were
never really meant for general use but their use was tolerated in
earlier versions of postgres when there were things you couldn't do
without them. Even in Oracle, I don't believe rowid bypasses
indexes, its more like an implicit SERIAL PRIMARY KEY field.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
