3 ms·
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)
by mozumder 10y ago
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)
- brianwawok 10y agoThe other change is now a single select can use multiple cores, so you could see how that scaled to 32, 64, 128 cores...
- qaq 10y agoOn 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.
- qaq 10y agoOutside of some very exotic scenarios you are IOPS bound on writes and not CPU bound.
- mozumder 10y agoIs that still a problem with cheap NVMe drives that can do 500k IOPS?
- Tostino 10y agoNot 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.
- user5994461 10y agoNot 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.
- qaq 10y agoNope but everyone is running in the "cloud" and there you are lucky to get 50K IOPS