Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date: 2014-05-07 14:31:07
Message-ID: 536A43AB.909@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 05/07/2014 10:12 AM, Andres Freund wrote:
> On 2014-05-07 10:07:07 -0400, Tom Lane wrote:
>> In the meantime, it seems like there is an emerging consensus that nobody
>> much likes the existing auto-tuning behavior for effective_cache_size,
>> and that we should revert that in favor of just increasing the fixed
>> default value significantly. I see no problem with a value of say 4GB;
>> that's very unlikely to be worse than the pre-9.4 default (128MB) on any
>> modern machine.
>>
>> Votes for or against?
> +1 for increasing it to 4GB and remove the autotuning. I don't like the
> current integration into guc.c much and a new static default doesn't
> seem to be worse than the current autotuning.
>
>

+1. If we ever want to implement an auto-tuning heuristic it seems we're
going to need some hard empirical evidence to support it, and that
doesn't seem likely to appear any time soon.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-05-07 14:40:02 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous Message Tom Lane 2014-05-07 14:29:36 Re: PGDLLEXPORTing all GUCs?