Thread: AW: OID wraparound: summary and proposal
> 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
> > > 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
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
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
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
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
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
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.
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
> 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
> 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
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