From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-patches(at)postgreSQL(dot)org |
Subject: | Re: WIP: 2nd-generation buffer ring patch |
Date: | 2007-05-29 22:46:46 |
Message-ID: | 21727.1180478806@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
I wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> 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 | Content-Type | Size |
---|---|---|
buffer-ring-3.patch.gz | application/octet-stream | 17.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-29 23:02:05 | Re: Regression tests |
Previous Message | Magnus Hagander | 2007-05-29 21:34:11 | Regression tests |