| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Ants Aasma <ants(at)cybertec(dot)at>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Clock sweep not caching enough B-Tree leaf pages? |
| Date: | 2014-04-28 13:04:51 |
| Message-ID: | CA+TgmoauVJxRPS9wT=gRCj0Zchr5d1FL7qwhp3UOCVjxXdUA0w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 21, 2014 at 6:38 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>> I feel that if there is no memory pressure, frankly it doesnt matter much
>> about what gets out and what not. The case I am specifically targeting is
>> when the clocksweep gets to move about a lot i.e. high memory pressure
>> workloads. Of course, I may be totally wrong here.
>
> Well, there's either memory pressure or there isn't. If there isn't then
> it's all moot *because we're not evicting anything*.
I don't think that's really true. A workload can fit within
shared_buffers at some times and spill beyond it at others. Every
time it fits within shared_buffers for even a short period of time,
the reference count of any buffer that's not ice-cold goes to 5 and we
essentially lose all knowledge of which buffers are relatively hotter.
Then, when we spill out again, evictions are random.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-04-28 13:36:03 | Re: shm_mq inconsistent behavior of SHM_MQ_DETACHED |
| Previous Message | Robert Haas | 2014-04-28 13:02:45 | Re: Clock sweep not caching enough B-Tree leaf pages? |