| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Clock sweep not caching enough B-Tree leaf pages? |
| Date: | 2015-04-20 14:56:41 |
| Message-ID: | CA+TgmoY3geOiMSt1zjQ=zbAB5ryxfhjBmPf9vRc2FMNBx_gMzg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 15, 2015 at 5:00 PM, Martijn van Oosterhout
<kleptog(at)svana(dot)org> wrote:
> I've been following this thread from the side with interest and got
> twigged by the point about loss of information. If you'd like better
> information about relative ages, you can acheive this by raising the
> cap on the usage count and dividing (or right-shifting) each sweep.
Yeah, I thought about that, too. It might be worth experimenting with.
> This would allow you to remember much more about about the relative
> worth of often used pages. With a cap of 32 you'd have the same effect
> as now where after 5 sweeps the buffer is evicted. Mathematically the
> count would converge to the number of times the block is used per
> sweep.
Hmm, interesting point. It's possible that we'd still have problems
with everything maxing out at 32 on some workloads, but at least it'd
be a little harder to max out at 32 than at 5.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2015-04-20 15:00:43 | Re: Clock sweep not caching enough B-Tree leaf pages? |
| Previous Message | Alvaro Herrera | 2015-04-20 14:32:43 | Re: Supporting src/test/modules in MSVC builds |