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 for
On Sat, Jan 16, 2010 at 4:09 AM, Greg Smith wrote:
> 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 i
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 muc
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 mentione
