Thread: AW: OID wraparound: summary and proposal

AW: OID wraparound: summary and proposal

From
Zeugswetter Andreas SB
Date:
> Strangely enough, I've seen no objection to optional OIDs
> other than mine. Probably it was my mistake to have formulated
> a plan on the flimsy assumption. 

I for one am more concerned about adding additional per
tuple overhead (moving from 32 -> 64bit) than loosing OID's
on some large tables. Imho optional OID's is the best way to combine 
both worlds. OID's only where you absolutely need them, and thus
a good chance that wraparound does not happen during the lifetime of 
one application. (And all this by reducing overhead, and not adding 
overhead :-)

Andreas 


Re: AW: OID wraparound: summary and proposal

From
Bruce Momjian
Date:
> 
> > Strangely enough, I've seen no objection to optional OIDs
> > other than mine. Probably it was my mistake to have formulated
> > a plan on the flimsy assumption. 
> 
> I for one am more concerned about adding additional per
> tuple overhead (moving from 32 -> 64bit) than loosing OID's
> on some large tables. Imho optional OID's is the best way to combine 
> both worlds. OID's only where you absolutely need them, and thus
> a good chance that wraparound does not happen during the lifetime of 
> one application. (And all this by reducing overhead, and not adding 
> overhead :-)

Agreed, the big selling point for me and optional oid's was removing
their overhead from the tuple header.  We need to trim that baby down! 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: OID wraparound: summary and proposal

From
ncm@zembu.com (Nathan Myers)
Date:
On Thu, Aug 02, 2001 at 09:28:18AM +0200, Zeugswetter Andreas SB wrote:
> 
> > Strangely enough, I've seen no objection to optional OIDs
> > other than mine. Probably it was my mistake to have formulated
> > a plan on the flimsy assumption. 
> 
> I for one am more concerned about adding additional per
> tuple overhead (moving from 32 -> 64bit) than loosing OID's
> on some large tables. Imho optional OID's is the best way to combine 
> both worlds. 

At the same time that we announce support for optional OIDs,
we should announce that, in future releases, OIDs will only be 
guaranteed unique (modulo wraparounds) within a single table.

Nathan Myers
ncm@zembu.com


Re: OID wraparound: summary and proposal

From
Hannu Krosing
Date:
Nathan Myers wrote:
> 
> On Thu, Aug 02, 2001 at 09:28:18AM +0200, Zeugswetter Andreas SB wrote:
> >
> > > Strangely enough, I've seen no objection to optional OIDs
> > > other than mine. Probably it was my mistake to have formulated
> > > a plan on the flimsy assumption.
> >
> > I for one am more concerned about adding additional per
> > tuple overhead (moving from 32 -> 64bit) than loosing OID's
> > on some large tables. Imho optional OID's is the best way to combine
> > both worlds.
> 
> At the same time that we announce support for optional OIDs,
> we should announce that, in future releases, OIDs will only be
> guaranteed unique (modulo wraparounds) within a single table.

What would the purpose of such an announcement be ???

OID is "Object IDentifier", meant to uniquely identify ANY object in an 
Object-Relational Database ,which PostgreSQL sometimes claims itself to
be.

If they are unique only within a single table then they are just 
system-supplied primary key fields without a default index - quite 
useless IMHO

I hope someone takes up the task of putting back some of the 
niftier features of original Postgres/postgres95 and adding more OO 
features. Deprecating OIDs won't help there .

--------------------
Hannu


Re: OID wraparound: summary and proposal

From
Tom Lane
Date:
ncm@zembu.com (Nathan Myers) writes:
> At the same time that we announce support for optional OIDs,
> we should announce that, in future releases, OIDs will only be 
> guaranteed unique (modulo wraparounds) within a single table.

Seems reasonable --- that will give people notice that we're thinking
about separate-OID-generator-per-table ideas.

Right now we don't really document any of these considerations,
but I plan to write something as part of the work I'm about to do.
        regards, tom lane


Re: AW: OID wraparound: summary and proposal

From
Hiroshi Inoue
Date:
Zeugswetter Andreas SB wrote:
> 
> > Strangely enough, I've seen no objection to optional OIDs
> > other than mine. Probably it was my mistake to have formulated
> > a plan on the flimsy assumption.
> 
> I for one am more concerned about adding additional per
> tuple overhead (moving from 32 -> 64bit) than loosing OID's
> on some large tables. Imho optional OID's is the best way to combine
> both worlds. OID's only where you absolutely need them, and thus
> a good chance that wraparound does not happen during the lifetime of
> one application. (And all this by reducing overhead, and not adding
> overhead :-)
> 

Hmm there seems to be an assumption that people could
know whether they need OID or not for each table.
I've had a plan in ODBC using OID and TID.
Few ODBC users know about ODBC spec. They rarely use
ODBC directly and use middlewares like Access etc.
Could they take care of the necessity of OIDs with
my plan ? Could they know when/how the middlewares 
use my new feature effectively ? To tell the truth,
I don't know it precisely.
OK, a user decided to create tables with OIDs unco
nditionally for ODBC but he may encounter the OID
wraparound problem instead....
I don't think that people use the feature with such
silly restrictions.

regards,
Hiroshi Inoue


Re: AW: OID wraparound: summary and proposal

From
Tom Lane
Date:
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Hmm there seems to be an assumption that people could
> know whether they need OID or not for each table.

A good point, and one reason not to make no-OIDs the default.  I'm
envisioning that people will turn off OIDs only for tables that they
know will be very large and that they know they don't need OIDs for.
        regards, tom lane


Re: AW: OID wraparound: summary and proposal

From
Hiroshi Inoue
Date:
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Hmm there seems to be an assumption that people could
> > know whether they need OID or not for each table.
> 
> A good point, and one reason not to make no-OIDs the default.  I'm
> envisioning that people will turn off OIDs only for tables that they
> know will be very large and that they know they don't need OIDs for.
>

AFAIK few people have voted *OIDs by default* in the
first place. It seems to mean that *default* would
naturally(essentially) be changed to *WITH NO OIDS*.
The followings are the result of vote which I remember
well.

regards,
Hiroshi Inoue

"Mikheev, Vadim" wrote:
> 
> > OK, we need to vote on whether Oid's are optional,
> > and whether we can have them not created by default.
> 
> Optional OIDs:      YES
> No OIDs by default: YES

Lamar Owen wrote:
> 
> [trimmed cc:list]
> On Wednesday 18 July 2001 17:09, Bruce Momjian wrote:
> > OK, we need to vote on whether Oid's are optional, and whether we can
> > have them not created by default.
> 
> [All the below IMHO]
> 
> OID's should be optional.
> 
> System tables that absolutely have to have OIDs may keep them.
> 
> No new OID usage, period.  Use some other unique primary key.
> 
> Default user tables to no OIDs.


Re: AW: OID wraparound: summary and proposal

From
Tom Lane
Date:
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> The followings are the result of vote which I remember
> well.

FWIW, I changed my vote ;-).  I'm not sure what Vadim and Lamar think
at the moment, but I thought you made good arguments.
        regards, tom lane


Re: OID wraparound: summary and proposal

From
Bruce Momjian
Date:
> ncm@zembu.com (Nathan Myers) writes:
> > At the same time that we announce support for optional OIDs,
> > we should announce that, in future releases, OIDs will only be 
> > guaranteed unique (modulo wraparounds) within a single table.
> 
> Seems reasonable --- that will give people notice that we're thinking
> about separate-OID-generator-per-table ideas.
> 
> Right now we don't really document any of these considerations,
> but I plan to write something as part of the work I'm about to do.

But why do that if we have sequences?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: AW: OID wraparound: summary and proposal

From
Bruce Momjian
Date:
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > The followings are the result of vote which I remember
> > well.
> 
> FWIW, I changed my vote ;-).  I'm not sure what Vadim and Lamar think
> at the moment, but I thought you made good arguments.

I think Vadim was clearly NOOID.  I vote OID.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


RE: OID wraparound: summary and proposal

From
"Dave Cramer"
Date:
I'm not sure this is related to the OID discussion, however I have seen
designs where a unique id is required for all the objects in the
database. 

This (IMO) this implies an int8 (or larger) sequence number. 

It would be nice if we could have different size sequences. Just thought
I'd throw that in.

Dave

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: August 3, 2001 9:22 AM
To: Tom Lane
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] OID wraparound: summary and proposal


> ncm@zembu.com (Nathan Myers) writes:
> > At the same time that we announce support for optional OIDs, we 
> > should announce that, in future releases, OIDs will only be 
> > guaranteed unique (modulo wraparounds) within a single table.
> 
> Seems reasonable --- that will give people notice that we're thinking 
> about separate-OID-generator-per-table ideas.
> 
> Right now we don't really document any of these considerations, but I 
> plan to write something as part of the work I'm about to do.

But why do that if we have sequences?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania
19026

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster