On Fri, Nov 1, 2019 at 3:15 PM Peter Geoghegan <pg@bowt.ie> wrote:
> 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.
Yeah! I mean, users who are using only 4-byte or smaller pass-by-value
quantities will be harmed, especially in cases where they are storing
a lot of them at the same time (e.g. sorting) and especially if they
double their space consumption and run out of their very limited
supply of memory. Those are all worthwhile considerations and perhaps
strong arguments against my proposal. But, people using 8-byte
oughta-be-pass-by-value quantities are certainly being harmed by the
present system. It's not a black-and-white thing, like, oh, 8-byte
datums on 32-bit system is awful all the time. Or at least, I don't
think it is.
> 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?
Yeah, I've had to fight with this multiple times, and so have other
people. It's a nuisance, and it causes bugs, certainly in draft
patches, sometimes in committed ones. It's not "free." If it's a cost
worth paying, ok, but is it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
