Re: Drop --disable-floatN-byval configure options?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Drop --disable-floatN-byval configure options?
Date: 2018-02-21 16:44:38
Message-ID: CA+TgmoaA=bq2ce=2uO5R-w+6gWhvw1y7HnGrJL3pgtOswwZX-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 21, 2018 at 10:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Per the discussion at
> https://www.postgresql.org/message-id/flat/54dfd2022c205eda9aa35b88923f027a%40postgrespro.ru
> it's become evident that use of --disable-float8-byval breaks at least one
> current regression test case, because it results in a large change in hash
> table size for float8 hash keys. While we could hack around that somehow,
> I think it would be a poor use of development effort. I have a modest
> substitute proposal: let's just drop the --disable-float4-byval and
> --disable-float8-byval configure options as of v11. Those don't have any
> impact on on-disk storage.

USE_FLOAT4_BYVAL seems completely pointless to me, but don't we need
USE_FLOAT8_BYVAL on machines where Datum is only 4 bytes wide? If
we've got to support that case on such machines, I'm not sure I'm in
favor of removing the option to have that behavior on other machines.
Being able to test such things without digging up a 32-bit machine is
useful.

--
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 Mark Dilger 2018-02-21 16:49:51 Re: [HACKERS] Constifying numeric.c's local vars
Previous Message Robert Haas 2018-02-21 16:33:18 Re: file cloning in pg_upgrade and CREATE DATABASE