> Some other databases have the notion of a ROWID which uniquely
identifies a row
> within a table. OID can be used for that, but it means if you use it,
you must
> limit the size of your whole database system.
Imho that is getting it all wrong. OID is *not* a suitable substitute
for other
db's
Zeugswetter Andreas SB SD wrote:
>
> > It seems to me, I guess and others too, that the OID mechanism should
> be on a
> > per table basis. That way OIDs are much more likely to be unique, and
> TRUNCATE
> > on a table should reset it's OID counter to zero.
>
> Seems to me, that this would be no
On Mon, 6 Aug 2001, mlw wrote:
> I think you are focusing too much on "ROWID" and not enough on OID. The issue
> at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
> decreases in price, the likelihood of people running into this limitation
> increases. I have run into OID
> It seems to me, I guess and others too, that the OID mechanism should
be on a
> per table basis. That way OIDs are much more likely to be unique, and
TRUNCATE
> on a table should reset it's OID counter to zero.
Seems to me, that this would be no different than a performance improved
version
of
I think you are focusing too much on "ROWID" and not enough on OID. The issue
at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
decreases in price, the likelihood of people running into this limitation
increases. I have run into OID problems in my curent project. Geez, 40
mlw wrote:
>
> Hiroshi Inoue wrote:
> >
> > The analog of ROWID in PostgreSQL is TID rather than OID
> > because TID is a physical address of a tuple within a table.
> > However there's a significant difference. Unfortunately TID
> > is transient. It is changed by UPDATE and VACUUM.
> > Though TI
Hiroshi Inoue wrote:
>
> The analog of ROWID in PostgreSQL is TID rather than OID
> because TID is a physical address of a tuple within a table.
> However there's a significant difference. Unfortunately TID
> is transient. It is changed by UPDATE and VACUUM.
> Though TIDs are unavailable for cri
The analog of ROWID in PostgreSQL is TID rather than OID
because TID is a physical address of a tuple within a table.
However there's a significant difference. Unfortunately TID
is transient. It is changed by UPDATE and VACUUM.
Though TIDs are unavailable for critical use, OIDs could
compensate t
Hannu Krosing wrote:
>
> mlw wrote:
> >
> > I posted this question earlier, but it looks like it never made it on.
> >
> > If you can control the OIDs on a per table basis, and some tables need not even
> > have any, why not let each table have its own OID range? Essentially, each
> > record will
Tom Lane wrote:
>
[Snipped]
I think making "WITHOUT OIDS" the default for table creation is the right thing
to do. Here is my reasoning:
An OID is a system wide limitation. 4B or 2B depending on sign-ness. (could
there be some bugs still lurking on high OIDs?) Since the OID is a shared
system w
mlw wrote:
>
> I posted this question earlier, but it looks like it never made it on.
>
> If you can control the OIDs on a per table basis, and some tables need not even
> have any, why not let each table have its own OID range? Essentially, each
> record will be numbered relative to 0 on its ta
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Based on the discussion so far, here is an attempt to flesh out the
>> details of what to do with OIDs for 7.2:
> Also OIDS should be promoted to 8-byte integers at some future time.
Perhaps, but I'm trying to focus on what to do for
Hannu Krosing <[EMAIL PROTECTED]> writes:
> That would probably be a problem with 4-byte OIDs, there is an ample
> supply of 8-byte ones
Sure, but I think we are still a few years away from being able to
assume that every platform of interest can support 8-byte OIDs (and
furthermore, won't see a
Maybe I'm being horribly stupid here, but
If the thinking is that some tables can escape having an OID, thus meaning OIDs
can be controlled by table, how hard would it be to have an OID range on a per
table basis?
Where each table to have its own notion of an OID, then OID wrap/depletion
sho
mlw <[EMAIL PROTECTED]> writes:
> how hard would it be to have an OID range on a per
> table basis?
The existing OID generator is a system-wide counter, and couldn't
reasonably be expected to do something like that.
There was some talk of (in essence) eliminating the present OID
generator mechan
15 matches
Mail list logo
