| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jim Nasby <jim(at)nasby(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Clock sweep not caching enough B-Tree leaf pages? |
| Date: | 2014-04-22 00:42:14 |
| Message-ID: | CAM3SWZTjf=Hdg-MFGJnyc5WNHo52qg92MvihD6U9MWVPP2yv9w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 21, 2014 at 5:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> We used to have one. It was a big bottleneck --- and this was years
> ago, when the buffer manager was much less scalable than it is today.
> (IIRC, getting rid of a central lock was one of the main advantages
> of the current clock sweep code over its predecessor.)
Yes, it was. This is a major advantage of clock sweep, and anything
that replaces it will need to maintain the same advantage. Didn't
someone indicate that clock sweep could beat ARC around that time,
presumably for this reason? If no one did, then my reading of a
variety of other papers on caching indicates that this is probably the
case.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2014-04-22 00:44:21 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |
| Previous Message | Peter Geoghegan | 2014-04-22 00:36:19 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |