Re: 64-bit sequences

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 64-bit sequences
Дата
Msg-id 20554.961822400@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: 64-bit sequences  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: query failed , don't know why
Следующее
От: Kovacs Zoltan Sandor
Дата:
Сообщение: Re: problem with ALTER GROUP