Tom Lane wrote:
>
> If OID remains at 4 bytes then this still isn't very satisfactory for
> tables that are likely to have more than 4 billion INSERTs in their
> lifetime. However, rather than imposing the cost of 8-byte OIDs
> everywhere, I'd be inclined to say that people who need unique
> identifiers in such tables should use user-defined columns generated
> from int8 sequences. (Obviously it would help if we created an
> int8-based sequence type... but that's certainly doable.) Perhaps in
> another few years, when all portability and performance issues with int8
> are history, we could think about changing OID to 8 bytes everywhere;
> but I don't think that's a good idea just yet.
Which are those platforms that currently lack 8-byte ints or whose
8-byte ints are limited to values below 2^31 ?
Managing huge tables on such platforms seems to be quite hard anyway .
I guess that the change of OID from 4 to 8 bytes could be carried out as
a
compile time option ?
> I do not think it is feasible to try to implement per-table OID
> generation for 7.2. What I'd like to do for 7.2 is continue with
> my previous proposal of making OID generation optional on a per-table
> basis (but the default is still to generate them). This seems to fit
> well with an eventual migration to per-table OIDs, since it still seems
> to me that some tables don't need them at all --- particularly, tables
> that are using an int8 column as key because wraparound is expected.
> Also, I will change pg_description as previously discussed, since this
> is clearly necessary in a per-table-OID world.
Changing pg_description to (table_oid,row_oid) seems reasonable for
other
reasons too, like going from description to the describee. I dont think
that pg_attribute is such a heavy OID-eater, except perhaps in case
where
each transaction creates and destroys temporary tables with very high
number of columns.
-----------------
Hannu
