Re: Remove configure --disable-float4-byval and --disable-float8-byval
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-11-02T03:14:47Z
Lists: pgsql-hackers
On 2019-11-02 11:47:26 +0900, Michael Paquier wrote: > On Fri, Nov 01, 2019 at 02:00:10PM -0400, Tom Lane wrote: > > Peter Geoghegan <pg@bowt.ie> writes: > >> Even Raspberry Pi devices (which can cost as little as $35) use 64-bit > >> ARM processors. It's abundantly clear that 32-bit platforms do not > >> matter enough to justify keeping all the SIZEOF_DATUM crud around. > > > > This line of argument seems to me to be the moral equivalent of > > "let's drop 32-bit support altogether". I'm not entirely on board > > with that. Certainly, a lot of the world is 64-bit these days, > > but people are still building small systems and they might want > > a database; preferably one that hasn't been detuned to the extent > > that it barely manages to run at all on such a platform. Making > > a whole lot of internal APIs 64-bit would be a pretty big hit for > > a 32-bit platform --- more instructions, more memory consumed for > > things like Datum arrays, all in a memory space that's not that big. > > I don't agree as well with the line of arguments to just remove 32b > support. Nobody is actually proposing that, as far as I can tell? I mean, by all means argue that the overhead is too high, but just claiming that slowing down 32bit systems by a measurable fraction is morally equivalent to removing 32bit support seems pointlessly facetious. Greetings, Andres Freund
Commits
-
Move configure --disable-float8-byval to pg_config_manual.h
- 4513d8b07bf3 13.0 landed
-
Remove configure --disable-float4-byval
- 2e4db241bfd3 13.0 landed