Tom Lane wrote: Updated version of Heikki's buffer ring patch, as per my comments here: http://archives.postgresql.org/pgsql-patches/2007-05/msg00449.php The COPY IN part of the patch is not there, pending resolution of whether we think it adds enough value to be worth uglifying heap_insert's
Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: The COPY IN part of the patch is not there, pending resolution of whether we think it adds enough value to be worth uglifying heap_insert's API for. I ran a series of tests, and it looks like it's not worth it. Great, I'll pull
Tom Lane wrote: Also, I tentatively reduced the threshold at which heapscans switch to ring mode to NBuffers/16; that probably needs more thought. Yeah. One scenario where threshold shared_buffers will hurt is if your shared_buffers = RAM size / 2. In that scenario, a scan on a table that
Heikki Linnakangas [EMAIL PROTECTED] writes: Also there's no attempt to not inflate usage_count, which means that synchronized scans will spoil the buffer cache as if we didn't have the buffer ring patch. As I said, these patches are hardly independent. If there's no easy solution, I think
I wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: If there's no easy solution, I think we could live with that, but Greg's suggestion of bumping the usage_count in PinBuffer instead of UnpinBuffer sounds like a nice solution to me. After thinking about it more, I'm a bit hesitant to do
On Tue, 29 May 2007, Tom Lane wrote: Do we have any decent way of measuring the effectiveness of the clock-sweep allocation algorithm? I put a view on top of the current pg_buffercache (now that it include usage_count) that shows what the high usage_count buffers consist of. Since they were
Greg Smith [EMAIL PROTECTED] writes: Based on my observations of buffer cache statistics, the number of pinned buffers at any time is small enough that in a reasonably sized buffer cache, I wouldn't expect a change in the pinned usage_count behavior to have any serious impact. Fair enough.