On Wed, Jun 27, 2012 at 10:40 AM, Andy Halsall wrote:
>
>
>> Date: Tue, 26 Jun 2012 08:42:34 -0500
>> Subject: Re: [PERFORM] Can I do better than this heapscan and sort?
>> From: mmonc...@gmail.com
>> To: halsall_a...@hotmail.com
>> CC: pgsql-performance@postgresql.org
>
>>
>> On Tue, Jun 26, 2012
Thank you.
Cheers,
WBL
Op 27 jun. 2012 14:59 schreef "Ants Aasma" het volgende:
> On Jun 27, 2012 2:29 PM, "Willy-Bas Loos" wrote:
> > Should i use a larger shared_buffers for the other cluster(s) too, so
> that i bypass the inefficient OS file-cache?
>
> Once the in-memory cluster has filled i
On Jun 27, 2012 2:29 PM, "Willy-Bas Loos" wrote:
> Should i use a larger shared_buffers for the other cluster(s) too, so
that i bypass the inefficient OS file-cache?
Once the in-memory cluster has filled its shared buffers, the pages go cold
for the OS cache and get replaced with pages of other c
On Wed, Jun 27, 2012 at 1:28 PM, Willy-Bas Loos wrote:
>
> * need fast writes on one cluster, so steal some memory to fit the DB in
> shared_buffers
>
> correction: READs, not writes. sry.
--
"Quality comes from focus and clarity of purpose" -- Mark Shuttleworth
On Wed, Jun 27, 2012 at 12:01 PM, Willy-Bas Loos wrote:
> I cannot follow that reasoning completely. Who needs OS level file cache
> when postgres' shared_buffers is better? The efficiency should go up again
> after passing 50% of shared buffers, where you would be caching everything
> twice.
> T
On Wed, Jun 27, 2012 at 9:34 AM, Hannu Krosing wrote:
> Check if you are CPU-bound. On a database which fits fully you may
> already be.
>
> Being CPU-bound is my goal.
That makes your answer a yes to me.
Only i'm afraid that this solution is not optimal.
Because i am stealing more resopurces fro
On Wed, 2012-06-27 at 00:16 +0200, Willy-Bas Loos wrote:
> Hi,
>
> I've read this:
> http://wiki.postgresql.org/wiki/Prioritizing_databases_by_separating_into_multiple_clusters
>
> But it doesn't really say anything about memory.
> If i can fit an extra cluster into it's shared buffer, it should