From: | Scott Carey <scott(at)richrelevance(dot)com> |
---|---|
To: | Scott Carey <scott(at)richrelevance(dot)com>, Mike Ivanov <mikei(at)activestate(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | Sean Ma <seanxma(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: random slow query |
Date: | 2009-06-30 21:20:04 |
Message-ID: | C66FCF94.8ECC%scott@richrelevance.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 6/30/09 1:08 PM, "Scott Carey" <scott(at)richrelevance(dot)com> wrote:
>
> A larger shared_buffers size can help if sequential scans are infrequent and
> kick out pages from the OS page cache.
> Postgres does not let sequential scans kick out index pages or pages
> accessed randomly from its buffer cache, but the OS (Linux) is more prone to
> that.
Let me qualify the above:
Postgres 8.3+ doesn't let full page scans push out pages from its
shared_buffers. It uses a ring buffer for full page scans and vacuums.
>
> Whether larger or smaller shared_buffers will help is HIGHLY load and use
> case dependant.
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Ivanov | 2009-06-30 21:39:50 | Re: random slow query |
Previous Message | Scott Carey | 2009-06-30 20:46:40 | Re: random slow query |