Re: DB cache size strategies - Mailing list pgsql-general

From Rick Gigger
Subject Re: DB cache size strategies
Date
Msg-id 402AA136.8050506@alpinenetworking.com
Whole thread Raw
In response to Re: DB cache size strategies  ("Ed L." <pgsql@bluepolka.net>)
Responses Re: DB cache size strategies
List pgsql-general
Has anyone discussed adding to postgres the ability to figure this out
on it's own.  Couldn't it gather some statistics about the kind of
resources that it is actually using and adjust accordingly.  You could
give it a max amount to use for the shared buffers but if it was so high
that it degraded performance postgres could just cut back on what it
actually used.

Is this even feasile?  Correct me if I am wrong but it seems that most
other dbs seem to work this way.

It would make installing a nice tuned postgres a much more turn key
operation.

rick


Ed L. wrote:
> On Wednesday February 11 2004 9:57, Tom Lane wrote:
>
>>"Ed L." <pgsql@bluepolka.net> writes:
>>
>>>Then what scenarios, if any, merit theory (2) over theory (1)?
>>
>>I'd only consider a large-cache setting on a machine that's dedicated to
>>running the database (where "dedicated" means "that's the only thing you
>>care about performance of", as in your first scenario).  Even then I'd
>>test it against the other way.  As Andrew Sullivan notes nearby, our
>>experience has been that the PostgreSQL buffer manager isn't all that
>>efficient about managing large caches.  It's possible that Jan's current
>>work will change that situation in 7.5, but I'd still test first ...
>
>
> Great.  Thx to all for feedback, very informative, interesting, and helpful
> in practice.
>
> Ed
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html

pgsql-general by date:

Previous
From: Vivek Khera
Date:
Subject: Re: Quad Xeon vs. Dual Itanium
Next
From: Joe Lester
Date:
Subject: No More Processes