Tom Lane wrote:
This is in fact exactly what the vacuum_cost_delay logic does.
It might be interesting to investigate generalizing that logic
so that it could throttle all of a backend's I/O not just vacuum.
In principle I think it ought to work all right for any I/O-bound
query.
So much
Robert Haas wrote:
Seems like you'd also need to think about priority inversion, if the
low-priority backend is holding any locks.
Right, that's what I was alluding to in the last part: the non-obvious
piece here is not how to decide when the backend should nap because it's
done too much
I've changed the setting a bit:
(1) Replaced 7.200 disk by a 10.000 one, still sata though.
(2) Inserting rows only 10x times (instead of 100x times)
but 80mb each, so having the same amount of 800mb in total.
(3) Changed the WAL path to the system disk (by the
great 'junction' trick
