| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Bastien Roucariès <rouca(at)debian(dot)org>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Detection of hadware feature => please do not use signal |
| Date: | 2024-11-01 06:16:32 |
| Message-ID: | 1637254.1730441792@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I wrote:
> Hmm. So it seems like we could do this:
> * Linux, FreeBSD, OpenBSD: do run-time test as recommended
> * Windows, macOS: assume that supported ARM hardware can do this
> * anything else: assume no hardware CRC
Actually, after chewing on that second point awhile longer,
how about this modest proposal:
* Drop all code for run-time determination of ARM CRC support.
Assume it's there unless user builds with a -march option that
says it definitely isn't.
Realistically, exactly who is going to be running Postgres 18+
on ARM hardware that lacks CRC support? I can think of lots of
projects that are more worthy of our time than this.
(Perhaps it's time to apply the same mindset to x86 CRC support
too?)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2024-11-01 06:32:28 | Re: Column changes such as an increase in varchar size, can cause extremely slow queries, and postgres should run analyze automatically. |
| Previous Message | Tom Lane | 2024-11-01 04:44:35 | Re: Detection of hadware feature => please do not use signal |