On Thu, Oct 31, 2019 at 9:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > float8 and related types are now hardcoded to pass-by-value or
> > pass-by-reference depending on whether the build is 64- or 32-bit, as
> > was previously also the default.
>
> I'm less happy with doing this. It makes it impossible to test the
> pass-by-reference code paths without actually firing up a 32-bit
> environment. It'd be fine to document --disable-float8-byval as
> a developer-only option (it might be so already), but I don't want
> to lose it completely. I fail to see any advantage in getting rid
> of it, anyway, since we do still have to maintain both code paths.
Could we get around this by making Datum 8 bytes everywhere?
Years ago, we got rid of INT64_IS_BUSTED, so we're relying on 64-bit
types working on all platforms. However, Datum on a system where
pointers are only 32 bits wide is also only 32 bits wide, so we can't
pass 64-bit quantities the same way we do elsewhere. But, why is the
width of a Datum equal to the width of a pointer, anyway? It would
surely cost something to widen 1, 2, and 4 byte quantities to 8 bytes
when packing them into datums on 32-bit platforms, but (1) we've long
since accepted that cost on 64-bit platforms, (2) it would save
palloc/pfree cycles when packing 8 byte quantities into 4-byte values,
(3) 32-bit platforms are now marginal and performance on those
platforms is not critical, and (4) it would simplify a lot of code and
reduce future bugs.
On a related note, why do we store typbyval in the catalog anyway
instead of inferring it from typlen and maybe typalign? It seems like
a bad idea to record on disk the way we pass around values in memory,
because it means that a change to how values are passed around in
memory has ramifications for on-disk compatibility.
rhaas=# select typname, typlen, typbyval, typalign from pg_type where
typlen in (1,2,4,8) != typbyval;
typname | typlen | typbyval | typalign
----------+--------+----------+----------
macaddr8 | 8 | f | i
(1 row)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
