On Fri, Nov 1, 2019 at 11:00 AM Tom Lane <t...@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
