From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Patrick Vedrines <patrick(dot)vedrines(at)adpcl(dot)com> |
Cc: | performance pgsql <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: CPU 0.1% IOWAIT 99% for decisonnal queries |
Date: | 2005-03-24 21:55:56 |
Message-ID: | 1111701356.11750.683.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2005-03-24 at 10:48 +0100, Patrick Vedrines wrote:
> > You've got 1.5Gb of shared_buffers and > 2Gb data. In 8.0, the scan
> will
> > hardly use the cache at all, nor will it ever, since the data is
> bigger
> > than the cache. Notably, the scan of B should NOT spoil the cache
> for A
> Are you sure of that ? Is Postgres able to say to OS: "don't use the
> cache for this query"?
PostgreSQL 8.0 has the ARC algorithm which prevents cache spoiling of
the shared_buffers, but has no direct influence over the OS cache.
> > Priming the cache is quite hard...but not impossible.
> > What will kill you on a shared_buffers that big is the bgwriter,
> which
> > you should turn off by setting bgwriter_maxpages = 0
> Is bgwriter concerned as my application applyes only SELECT ?
With very large shared_buffers the bgwriter's default settings are a
problem. You don't need it, so I suggest turning it off.
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Otto Blomqvist | 2005-03-24 23:04:24 | Re: pg_autovacuum not having enough suction ? |
Previous Message | Matthew T. O'Connor | 2005-03-24 20:25:48 | Re: pg_autovacuum not having enough suction ? |