On Wed, Feb 11, 2004 at 12:26:06AM -0500, Tom Lane wrote:
> Giving PG half the RAM is counterproductive no matter what --- that
> pretty much guarantees that every page that's in RAM will be in RAM
> twice, once in PG buffers and once in kernel buffers. The two
Well, unless you're using an OS whi
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Ed L.") wrote:
> On Tuesday February 10 2004 3:48, scott.marlowe wrote:
>> On Tue, 10 Feb 2004, Ed L. wrote:
>> > Interesting. Why leave very large tables to the kernel instead
>> > of the db cache? Assuming a dedicated DB server and
On Wednesday February 11 2004 9:57, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> 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
On Wednesday February 11 2004 9:18, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > In general, would it be true to say that if one does *not* anticipate
> > contention for kernel disk cache space from non-DB processes (e.g., the
> > dedicated db server), then you probably want to use the
"Ed L." <[EMAIL PROTECTED]> 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 scenar
"Ed L." <[EMAIL PROTECTED]> writes:
> In general, would it be true to say that if one does *not* anticipate
> contention for kernel disk cache space from non-DB processes (e.g., the
> dedicated db server), then you probably want to use theory (1)? If one
> *does* anticipate such contention (e.g
On Tuesday February 10 2004 11:17, Tom Lane wrote:
>
> Well, if you go *really* small then you find a lot of CPU time gets
> wasted shuffling data from kernel cache to PG cache. The sweet spot
> for theory (1) seems to be to set shared_buffers in the range of 1000 to
> 1 buffers. (Time was th
On Wed, 11 Feb 2004, NTPT wrote:
> Take 1900 ms.. In this case i try to increase effective_cache_size step
> by step 64,128,256,512,1024 but increase effective_cache_size up from
> 512 have no dramatic impact on performance.
Note that effective_cache_size ONLY affects the query plan chosen. I
On Wednesday 11 February 2004 09:42, NTPT wrote:
>
> It seems that :
>
> 1: Settings memory limits too high, whnen machine start using swap space
> is WROSE then give postgres as low memory as possible.
Swapping is always bad news.
> 2: settings of sort_mem have bigger impact on performance th
On Tue, Feb 10, 2004 at 01:20:32PM -0700, Ed L. wrote:
> On Friday January 30 2004 6:06, Martijn van Oosterhout wrote:
> > On Fri, Jan 30, 2004 at 03:19:56PM -0700, Ed L. wrote:
> > >
> > > I'm also curious about the relationship of DB shared buffer cache to
> > > the linux/hpux kernel caches. ...
On Friday January 30 2004 6:06, Martijn van Oosterhout wrote:
> On Fri, Jan 30, 2004 at 03:19:56PM -0700, Ed L. wrote:
> >
> > I'm also curious about the relationship of DB shared buffer cache to
> > the linux/hpux kernel caches. ...
>
> Whenever the database needs a block not in memory it get loa
11 matches
Mail list logo
