On Thu, Feb 18, 2010 at 8:46 PM, Jayadevan M <jayadevan.maym...@ibsplc.com> 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.
Oracle and postgres are definitely different here. There's really no equivalent to rowid in pgsql. oid has no special optimizations. An indexed PK of a serial is about as good as it gets, possibly clustered. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
