On Fri, Nov 1, 2019 at 11:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I don't think that those two things are equivalent at all. There may
even be workloads that will benefit when run on 32-bit hardware.
Having to palloc() and pfree() with 8 byte integers is probably very
slow.
> 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.
Even the very low end is 64-bit these days. $100 smartphones have
64-bit CPUs and 4GB of ram. AFAICT, anything still being produced that
is recognizable as a general purpose CPU (e.g. by having virtual
memory) is 64-bit. We're talking about a change that can't affect
users until late 2020 at the earliest.
I accept that there are some number of users that still have 32-bit
Postgres installations, probably because they happened to have a
32-bit machine close at hand. The economics of running a database
server on a 32-bit machine are already awful, though.
> It seems especially insane to conclude that we should pull the plug
> on such use-cases just to get rid of one obscure configure option.
> If we were expending any significant devel effort on supporting
> 32-bit platforms, I might be ready to drop support, but we're not.
> (Robert's proposal looks to me like it's actually creating new work
> to do, not saving work.)
The mental burden of considering "SIZEOF_DATUM == 4" and
"USE_FLOAT8_BYVAL" is a real cost for us. We maintain non-trivial
32-bit only code for numeric abbreviated keys. We also have to worry
about pfree()'ing memory when USE_FLOAT8_BYVAL within
heapam_index_validate_scan(). How confident are we that there isn't
some place that leaks memory on !USE_FLOAT8_BYVAL builds because
somebody forgot to add a pfree() in an #ifdef block?
--
Peter Geoghegan
