| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Gaetano Mendola" <mendola(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: shared_buffers performance |
| Date: | 2008-04-14 19:58:21 |
| Message-ID: | 874pa4gqea.fsf@oxford.xeocode.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> The transition domain where performance drops dramatically as the database
>> starts to not fit in shared buffers but does still fit in filesystem cache.
>
> It looks to me like the knee comes where the DB no longer fits in
> filesystem cache.
That does seem to make a lot more sense. I think I misread the units of the
size of the accounts table. Reading it again it seems to be in the 1.5G-2G
range for the transition which with indexes and other tables might be starting
to stress the filesystem cache -- though it still seems a little low.
I think if I squint I can see another dropoff at the very small scaling
numbers. That must be the point where the database is comparable to the shared
buffers size. Except then I would expect the green and blue curves to be
pushed to the right a bit rather than just havin a shallower slope.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2008-04-14 20:08:48 | Re: shared_buffers performance |
| Previous Message | Tom Lane | 2008-04-14 19:31:54 | Re: shared_buffers performance |