Re: Making type Datum be 8 bytes everywhere
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2025-07-23T19:00:04Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid faulty alignment of Datums in build_sorted_items().
- 09036dc71c68 19 (unreleased) landed
-
Grab the low-hanging fruit from forcing USE_FLOAT8_BYVAL to true.
- ee54046601de 19 (unreleased) landed
-
Grab the low-hanging fruit from forcing sizeof(Datum) to 8.
- 6aebedc38497 19 (unreleased) landed
-
Make type Datum be 8 bytes wide everywhere.
- 2a600a93c7be 19 (unreleased) landed
-
Mop-up for Datum conversion cleanups.
- 665c3dbba497 19 (unreleased) landed