Oh good, I put my SaaS (running mostly on Linode) up yesterday, then this happens. Can't wait for Linode to apply this patch to their infrastructure :(

I'm cursed when it comes to timing. It's like when I bought that house in 2007, held onto it waiting for the market to recover, then tried to sell it only to find out my tenants had been using it to operate a rabbit-breeding business for years and completely trashed the place (thank you, useless property manager), forcing me to sell it at a loss anyway (6 months ago).

Also, I hate rabbits now. And I veered off topic, sorry.

You might try luck to sell this as comedy/drama movie script. :)

> Also, I hate rabbits now. And I veered off topic, sorry.

Well I guess you're not the right person to without about a great ninja-rockstar position at our new RaaS startup.

/one has to joke sometimes to avoid crying over taking a 30% hit in costs... over a stupid CPU bug

I would love to see some SQL Server benchmarks on this patch

SQL Server license disallows publishing of the results of benchmarking (much like Oracle does)

Wait, really? That's kind of messed up.

Remarkable that no throwaway HN accounts considered that a challenge.

Likely very similar to the postgres benchmarks. Fundamentally a RDBMS needs to sync each transaction commit to the log file on disk and that sync is always a syscall. If your DB is doing thousands tx/sec to low latency flash and you rely on that low latency, you're going to get hit.

Note that the postgres benchmark numbers passed around (most based on my benchmarks) are readonly. For write based workloads the overhead is likely going to be much smaller in nearly all cases, there's just more independent workload. The overhead in the readonly load profiles comes near entirely from the synchronous client<->server communication, if you can avoid that for workloads (using pipelining, other batching techniques) the overhead's going to be smaller.