Horton
Menu

Re: Making type Datum be 8 bytes everywhere

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joe Conway <mail@joeconway.com>
Cc: Michael Paquier <michael@paquier.xyz>, Peter Eisentraut <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2025-08-09T16:44:51Z
Lists: pgsql-hackers

Attachments

Joe Conway <mail@joeconway.com> writes:
> On 8/8/25 21:14, Tom Lane wrote:
>> I have just realized that this proposal has a rather nasty defect.
>> ...
>> On the positive side, even if there are any SP-GiST opclasses that
>> are at risk, the population of installations using them on 32-bit
>> installs has got to be pretty tiny.

> I bet it is indistinguishable from zero...

That's my bet too.

>> And the worst-case answer is that you'd have to reindex such indexes
>> after pg_upgrade.

> ...and this seems like a reasonable answer if anyone pops up.

>> Do we think that making this change is valuable enough to justify
>> taking such a risk?

> yes +1

I've now fleshed out the patch series with some cleanup of code that's
been rendered dead.  The 0001 patch is nearly the same as before,
but thanks to all the work Peter did, it doesn't trigger a pile of
gcc warnings (at least, not for me).

			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 →

  1. Avoid faulty alignment of Datums in build_sorted_items().

  2. Grab the low-hanging fruit from forcing USE_FLOAT8_BYVAL to true.

  3. Grab the low-hanging fruit from forcing sizeof(Datum) to 8.

  4. Make type Datum be 8 bytes wide everywhere.

  5. Mop-up for Datum conversion cleanups.