Re: Doubts about oid

From: Jayadevan M <Jayadevan(dot)Maymala(at)ibsplc(dot)com>
To: adrian(dot)klaver(at)gmail(dot)com
Cc: pgsql-general(at)postgresql(dot)org, pgsql-general-owner(at)postgresql(dot)org
Subject: Re: Doubts about oid
Date: 2010-02-19 03:46:14
Message-ID: OF0AC4BB8B.7A465AA8-ON652576CF.00138367-652576CF.0014BABA@ibsplc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

Thanks for your reply,
Regards,
Jayadevan

DISCLAIMER:

"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2010-02-19 04:08:15 Re: Doubts about oid
Previous Message Lew 2010-02-19 03:34:26 Re: GROUP BY column alias?