From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance |
Date: | 2011-04-14 03:39:44 |
Message-ID: | BANLkTik41qQZPWxk=OGe28vYqkvpFa22Gw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Apr 13, 2011 at 5:26 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> Workload A: Touches just a very small portion of the database, to the
> 'active' part actually fits into the memory. In this case the cache hit
> ratio can easily be close to 99%.
>
> Workload B: Touches large portion of the database, so it hits the drive
> very often. In this case the cache hit ratio is usually around RAM/(size
> of the database).
I've had this kind of split-brain operation in the past, where 99% of
all accesses would be cached, and the 1% that weren't needed their own
tuning. Luckily you can tune by user (alter user set random_page_cost
etc) so I was able to do that. One of the best features of pgsql
imnsho.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-04-14 04:23:23 | Re: Linux: more cores = less concurrency. |
Previous Message | Joshua D. Drake | 2011-04-14 00:37:05 | Re: Performance |