Re: 64-bit sequences - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 64-bit sequences
Date
Msg-id 20554.961822400@sss.pgh.pa.us
Whole thread Raw
In response to Re: 64-bit sequences  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Similar subject: What about making the oid 64-bit?

> Again, a 64bit vs 32 bit issue. We have "pass by value" and "pass by
> reference" data types, and we have conventionally made everything bigger
> than 32bits a "by reference" type. Going to a 64bit OID or SERIAL type
> may mess with that convention, but it may be good to revisit this and
> remind ourselves why we have that convention in the first place.

I think it would be completely impractical to convert Oid to a pass-by-
reference type --- the palloc() overhead would be intolerable.  However,
on machines where it's possible to make Datum a 64-bit integer type,
we could support 64-bit Oids.  On those machines where pointers are 64
bits, there wouldn't even be any performance cost because Datum has to
be 64 bits anyway.

I have actually had something like this in the back of my mind while
working on the fmgr conversion.  With sufficiently disciplined use of
DatumGetFoo and FooGetDatum macros everywhere, it would become fairly
transparent whether Datum is 32 or 64 bits and whether 64-bit types
are pass-by-value or pass-by-reference.  Eventually I'd like to see
compile-time options for the size of Oid and for whether int8,
float4, and float8 are pass-by-val or -by-ref.  There's still a lot
of tedious code-cleanup gruntwork to be done before that can happen,
though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: query failed , don't know why
Next
From: Kovacs Zoltan Sandor
Date:
Subject: Re: problem with ALTER GROUP