On Wed, Jan 9, 2013 at 3:39 PM, Josh Berkus wrote:
>> It seems to me that pgfincore has the smarts we need to know about that,
>> and that Cédric has code and refenrences for making it work on all
>> platforms we care about (linux, bsd, windows for starters).
>
> Well, fincore is Linux-only, and f
Dimitri,
> It seems to me that pgfincore has the smarts we need to know about that,
> and that Cédric has code and refenrences for making it work on all
> platforms we care about (linux, bsd, windows for starters).
Well, fincore is Linux-only, and for that matter only more recent
versions of linu
Tom Lane writes:
> Well, the problem of "find out the box's physical RAM" is doubtless
> solvable if we're willing to put enough sweat and tears into it, but
> I'm dubious that it's worth the trouble. The harder part is how to know
> if the box is supposed to be dedicated to the database. Bear i
On Wed, Jan 9, 2013 at 2:01 AM, Josh Berkus wrote:
> All,
>
> >> Well, the problem of "find out the box's physical RAM" is doubtless
> >> solvable if we're willing to put enough sweat and tears into it, but
> >> I'm dubious that it's worth the trouble. The harder part is how to know
> >> if the
All,
>> Well, the problem of "find out the box's physical RAM" is doubtless
>> solvable if we're willing to put enough sweat and tears into it, but
>> I'm dubious that it's worth the trouble. The harder part is how to know
>> if the box is supposed to be dedicated to the database. Bear in mind
>
On 01/08/2013 08:08 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane wrote:
... And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.
For the record, I don't beli
Robert Haas writes:
> On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane wrote:
>> ... And I don't especially like the idea of trying to
>> make it depend directly on the box's physical RAM, for the same
>> practical reasons Robert mentioned.
> For the record, I don't believe those problems would be part
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire
>> wrote:
>>> Rather, I'd propose the default setting should be "-1" or something
>>> "default" and "automagic" that works most of the time (but not all).
>
>> A cruder heuris
Robert Haas writes:
> On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire wrote:
>> Rather, I'd propose the default setting should be "-1" or something
>> "default" and "automagic" that works most of the time (but not all).
> A cruder heuristic that might be useful is 3 * shared_buffers.
Both parts
On Tue, Jan 8, 2013 at 05:23:36PM -0500, Robert Haas wrote:
> > Rather, I'd propose the default setting should be "-1" or something
> > "default" and "automagic" that works most of the time (but not all).
>
> +1. I've found that a value of three-quarters of system memory works
> pretty well most
On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire wrote:
> On Tue, Jan 8, 2013 at 11:39 AM, Merlin Moncure wrote:
>> Reference:
>> http://postgresql.1045698.n5.nabble.com/Simple-join-doesn-t-use-index-td5738689.html
>>
>> This is a pretty common gotcha: user sets shared_buffers but misses
>> the es
On Tue, Jan 8, 2013 at 11:39 AM, Merlin Moncure wrote:
> Reference:
> http://postgresql.1045698.n5.nabble.com/Simple-join-doesn-t-use-index-td5738689.html
>
> This is a pretty common gotcha: user sets shared_buffers but misses
> the esoteric but important effective_cache_size. ISTM
> effective_c
101 - 112 of 112 matches
Mail list logo
