AWS engineers most often fork the open source repositories and keep sll their patches only to them, they rarely submit those upstream.

Disclosure: I work at AWS where I build the cloud infrastructure that powers EC2.

One example of a patch that can help with MySQL performance on Graviton2 processors is enabling the Large System Extension atomic operations. You can find our pull request for enabling that here: https://github.com/mysql/mysql-server/pull/302

Unfortunately it seems that their CLA bot auto-closed the submission. Thank you for your comment here on HN, because it prompted me to go check on this PR and it led me to this discovery.

[edit] See also the discussion here about compiler flag defaults for PostgreSQL, to provide optimizations while retaining compatibility for Arm processors without LSE: https://www.postgresql.org/message-id/flat/099F69EE-51D3-421...

As an aside that conversation on your Github pull request is pretty funny from a sadlol perspective. Thanks for submitting the pull request even when the bot closed the conversation even though you said you submitted the OCA.

This is the automated future that's already here.

I can imagine in the future:

Automated appeals bot: "Thank you for submitting your appeals letter for appealing the Case decision number XYZ. We will need you to submit a signature"

Wrongfully incarcerated person: "OK I will need to find time to get to another computer so I can submit my digital signature"

Automated appeals bot: "Please submit your signature. This is mandatory for all appeals"

Wrongfully incarcerated person: "OK after negotiating with the guards I finally got a computer where I can sign. I've signed my appeal application"

Automated appeals bot: "As we didn't get a signature from you in the set amount of time, your appeals application has been closed. The rest of the sentence will be executed."

Wrongfully incarcerated person is executed.

AWS provides the binary for RDS users, right? Why do you need to block on upstream for these improvements?

We aren't blocking on upstream for these improvements. You're right that it is easy to optimize only the engine builds that are executing via RDS deployments. But getting optimizations upstream as far as possible yields the maximum downstream effect. And we want open-source software to run exceptionally well on all Arm processors, including Graviton2, no matter who you get your binaries from, or if you build them yourself.

> 20+ years of software optimization on x86 gives it a nice lead

Not as much as one would hope. x86 is a very complex architecture.

Note that most cellphones run ARM, there are many years of compiler optimizations as well.

> Note that most cellphones run ARM, there are many years of compiler optimizations as well.

Compilation, yes, runtime for DBs? Unlikely.