From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Aleksander Alekseev" <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is *fast* 32-bit support still important? |
Date: | 2024-08-05 12:54:39 |
Message-ID: | da33e4c6-d071-4c42-9564-4269d7c73aca@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 5, 2024, at 14:24, Aleksander Alekseev wrote:
>> Could we add a text message that is displayed to a user,
>> when compiling PostgreSQL on a 32-bit platform?
>
> What would be actionable items depending on the results? Option A:
> someone claims to use PostgreSQL on 32-bit hardware. Option B: no one
> admits that they use PostgreSQL on 32-bit hardware (but maybe someone
> actually does and/or will in the future). Regardless of the results
> you can't drop the support of 32-bit software (until it gets as
> difficult and pointless as with AIX that was dropped recently) and it
> will not tell you how slow the 32-bit version of PostgreSQL can be.
>
> If there are no actionable items why create a poll?
Never suggested *dropping* 32-bit support; that's a different question.
However, if we were to receive input from 32-bit PostgreSQL users explaining
why they need *high performance*, then I imagine that could affect how we
feel about 32-bit optimizations.
Right now, there doesn't seem to be a consensus on whether we should optimize
for 32-bit or not.
On the one hand, we have commit 5e1f3b9 that says:
"While it adds some space on 32-bit machines, we aren't optimizing
for that case anymore."
On the other hand, we have the ongoing work on optimizing numeric_mul,
where a patch is suggested with extra code to optimize for 32-bit.
I agree, however, that the absence of any comments from such a poll would not
give us any more information.
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2024-08-05 13:12:46 | Re: SQL Property Graph Queries (SQL/PGQ) |
Previous Message | Thomas Munro | 2024-08-05 12:43:26 | BlastRADIUS mitigation |