Hacker News new | ask | show | jobs
by brianwawok 3397 days ago
This is from 2012: http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-abo...

My guess is the 1 socket options scales great. 2 sockets are are less than ideal, and you will not double the 1 socket performance.

3 comments

Yeah, every single release since then has had work done on scaling Postgres up on a single machine. They have been working on eliminating bottlenecks one after another to allow it to scale on crazy numbers of cores.

I've seen benchmarks on the -hackers mailing list with 88 core Intel servers (4s 22c) in regard to eliminating bottlenecks when you have that many cores. So even if it's not 100% there yet, it will be soon.

I'd like to see this data on Postgres scaling updated, with more info on the write scaling as well. (the chart appears to be for SELECT queries only)
The other change is now a single select can use multiple cores, so you could see how that scaled to 32, 64, 128 cores...
On highly concurrent PG systems by when using parallel queries you are sacrificing throughput for better latency. You really don't want to use more than a fairly small number of workers per single select.
Outside of some very exotic scenarios you are IOPS bound on writes and not CPU bound.
Is that still a problem with cheap NVMe drives that can do 500k IOPS?
Not a problem at all if you provision your server properly so you aren't IOPS bound, though there are plenty of databases which simply won't fit on NVMe drives, so in those cases, yes it could still be a problem.
Not likely to be a problem if you have FusionIO drives. Likely to be a problem sooner or later on everything else. A definitive recurrent issues on all cloud providers and NAS/network drives.
Nope but everyone is running in the "cloud" and there you are lucky to get 50K IOPS
This is one of the reasons I don't run in the cloud.
same here
I've seen decent enough scaling on 8 socket servers. There's still some bottlenecks if you have a lot of very short queries (because there's some shared state manipulations per query & transaction), but in a lot of cases postgres scales quite well even at those sizes.