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 that because it
> will change the interaction with the clock sweep for buffers that stay
> pinned for awhile.  I had suggested making the clock sweep not decrement
> usage_count of a pinned buffer, but I think that would change the
> fairness of the algorithm.  OTOH it may not matter that much if we just
> move the usage_count increment and leave the clock sweep alone.  Do we
> have any decent way of measuring the effectiveness of the clock-sweep
> allocation algorithm?

Despite above misgivings, here's a version of the patch that moves
usage_count incrementing to PinBuffer instead of UnpinBuffer.  It does
seem a good bit cleaner.

                        regards, tom lane

Attachment: binalDuLkt1Ft.bin
Description: buffer-ring-3.patch.gz

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to