On Fri, Nov 1, 2019 at 3:15 PM Peter Geoghegan <p...@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
