Re: Remove configure --disable-float4-byval and --disable-float8-byval

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove configure --disable-float4-byval and --disable-float8-byval
Date: 2019-11-01 14:41:19
Message-ID: CA+TgmoaCyw26S7wkTshAJKpjP5zfVnLiBSWYYvn5kT7rh3vrZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 31, 2019 at 9:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2019-11-01 14:48:29 Re: On disable_cost
Previous Message Tomas Vondra 2019-11-01 14:17:51 Re: Adding percentile metrics to pg_stat_statements module