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: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers@lists.postgresql.org, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>
Date: 2025-07-31T15:18:03Z
Lists: pgsql-hackers 
Peter Eisentraut <peter@eisentraut.org> writes:
> On 18.07.25 02:09, Tom Lane wrote:
>> The attached patch switches to 8-byte Datums everywhere, but
>> doesn't make any effort to remove the now-dead code.

> Is the plan to support only exactly Datums of size 8, or Datums of size 
> at least 8?

My plan was to hard-wire it at 8 permanently.  It's pretty hard to
believe that there will be hardware on which sizeof(Datum) == 16
would be a reasonable choice anytime while people are still using C.
You'd want 16-byte registers and native operations, and I don't
see any manufacturers headed in that direction.

It could be reasonable to keep provisions for that as long as we still
have active hardware and testing for two different sizes of Datum.
However, once we kill off testing of sizeof(Datum) == 4, I think the
code will acquire hard assumptions that sizeof(Datum) == 8 pretty
soon.  If I were upset with that prospect I would not be proposing
this change.

			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.