From: | David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: Initdb-time block size specification |
Date: | 2023-08-31 16:13:18 |
Message-ID: | CAOxo6XJsJFD_vSTVWYCUdnLt9OhxYK8Mk35O_MXU-A262eKVMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I was definitely hand-waving additional implementation here for
> non-native 128 bit support; the modulus algorithm as presented
> requires 4 times the space as the divisor, so a uint16 implementation
> should work for all 64-bit machines. Certainly open to other ideas or
> implementations, this was the one I was able to find initially. If
> the 16bit approach is all that is needed in practice we can also see
> about narrowing the domain and not worry about making this a
> general-purpose function.
Here's a patch atop the series which converts to 16-bit uints and
passes regressions, but I don't consider well-vetted at this point.
David
Attachment | Content-Type | Size |
---|---|---|
0001-Switch-to-using-only-16-bit-to-avoid-128-bit-require.patch | application/octet-stream | 2.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | John Morris | 2023-08-31 16:18:57 | Re: Add tracking of backend memory allocated to pg_stat_activity |
Previous Message | David Christensen | 2023-08-31 16:01:02 | Re: Initdb-time block size specification |