Re: Making type Datum be 8 bytes everywhere - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Making type Datum be 8 bytes everywhere
Date
Msg-id 1353250.1753297204@sss.pgh.pa.us
Whole thread Raw
In response to Re: Making type Datum be 8 bytes everywhere  (Andres Freund <andres@anarazel.de>)
Responses Re: Making type Datum be 8 bytes everywhere
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2025-07-18 13:24:32 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> One class of complaints is about DatumGetPointer() and
>>> PointerGetDatum() casting between different sizes:

>> We might be able to silence those with intermediate casts to uintptr_t,
>> perhaps?

> Yep, that does the trick.

Cool, thanks for checking.

>>> I've not looked into the performance consequences.  We probably
>>> should at least try to measure that, though I'm not sure what
>>> our threshold of pain would be for deciding not to do this.

> The hard bit would be to determine what workload to measure.  Something like
> pgbench probably won't suffer meaningfully, there's just not enough passing of
> values around.

I'm disinclined to put in a huge amount of effort looking for the
worst case.  We established long ago that we weren't going to
optimize for 32-bit anymore.  So as long as this doesn't completely
tank performance on 32-bit, I'm satisfied.  I'd almost say that
if standard pgbench doesn't notice the change, that's good enough.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)
Next
From: Alexander Lakhin
Date:
Subject: Re: [Buildfarm:84] Re: stats.sql might fail due to shared buffers also used by parallel tests