From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <gsstark(at)mit(dot)edu> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ACM Paper relevant to our buffer algorithm |
Date: | 2007-07-04 16:20:24 |
Message-ID: | 26567.1183566024@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <gsstark(at)mit(dot)edu> writes:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> I'm still struggling to understand why and how bgwriter increases performance.
>> Under what circumstances, what workload?
>>
>> The only benefit I can see is that it moves the write() of a page out of the
>> critical path. But as long as the OS cache can absorb the write, it should be
>> very cheap compared to doing real I/O.
> Well you can't keep writing indefinitely faster than the i/o subsystem can
> execute the writes. Eventually the kernel will block your write until a kernel
> buffer becomes free. Ie, throttle your writes to the actual write bandwidth
> available.
Right. Also, a buffer write isn't "merely" a kernel call --- for
instance, you might have to flush some more WAL before you can execute
the write, and there are cases where you'd have to fsync the write
yourself (ie, if you can't pass it off to the bgwriter). The more of
that we can take out of foreground query paths, the better.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-04 16:24:03 | Re: Dead code as a result of plan cache invalidation? |
Previous Message | Darcy Buskermolen | 2007-07-04 15:32:43 | Re: Why so many out-of-disk-space failures on buildfarm machines? |