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 по дате отправления: