3 ms·

> Nothing we did could get us much above 50% saturation on the disk array, CPU, or networking. What you wrote basically makes no sense unless you are doing con

> Nothing we did could get us much above 50% saturation on the disk array, CPU, or networking. What you wrote basically makes no sense unless you are doing continuous table scans (ask any DBA and see how puzzled they look.) Production MySQL and Postgres master databases that I administer typically have uptime loads of 0.1 to 0.2 on Linux, processing 5,000 qps. Regarding placeholders and bind parameters (those are different things), how they work depends mostly on your client library. For example, some libraries do rewrite placeholders with string pasting, so verify that. YMMV. Source: I am a DBA.

anarazel 7y ago
> Production MySQL and Postgres master databases that I administer typically have uptime loads of 0.1 to 0.2 on Linux, processing 5,000 qps. I have worked with plenty production postgres instances that have much much higher loads. As in > 100 (on larger machines obviously). It's pretty easy to have workloads where the hot data set fits mostly into RAM - and if that's the case the read portion of that workload is usually bound by context switches and CPU processing time of the queries. Far from every workload has enough queries to utilize a machine with plenty cores, but there's also a lot where that's trivial.
hinkley 7y ago
If you are getting a lower qps out of a machine than you expect and none of the hardware subsystems are saturated then something is wrong, and it’s not table scans. A table scan would be maxing iops for disk or memory or both, right? When was 9i released? Are you qualified to compare 15 year old hardware running a 15 year old database on a 15 year old OS to what you have going on now? (Hell, I’m not even sure it was Intel hardware. Odds are reasonably good that was on an Ultrasparc, since that’s what our customers were running)

3 ms·

> Nothing we did could get us much above 50% saturation on the disk array, CPU, or networking. What you wrote basically makes no sense unless you are doing con

by redis_mlc 7y ago

anarazel 7y ago
> Production MySQL and Postgres master databases that I administer typically have uptime loads of 0.1 to 0.2 on Linux, processing 5,000 qps. I have worked with plenty production postgres instances that have much much higher loads. As in > 100 (on larger machines obviously). It's pretty easy to have workloads where the hot data set fits mostly into RAM - and if that's the case the read portion of that workload is usually bound by context switches and CPU processing time of the queries. Far from every workload has enough queries to utilize a machine with plenty cores, but there's also a lot where that's trivial.
hinkley 7y ago
If you are getting a lower qps out of a machine than you expect and none of the hardware subsystems are saturated then something is wrong, and it’s not table scans. A table scan would be maxing iops for disk or memory or both, right? When was 9i released? Are you qualified to compare 15 year old hardware running a 15 year old database on a 15 year old OS to what you have going on now? (Hell, I’m not even sure it was Intel hardware. Odds are reasonably good that was on an Ultrasparc, since that’s what our customers were running)