Re: Version 7 question

I think you're confusing effect_cache_size with shared_buffers.
effective_cache_size tells the planner about how much disk cache the OS is
using for postgresql behind its back, so to speak.

On Tue, 1 Jul 2003, Michael Mattox wrote:

> My understanding is to use as much effect cache as possible, so figure out
> how much ram you need for your other applications & OS and then give the
> rest to postgres as effective cache.
>
> What I learned to day is the shared_buffers 25% of RAM guideline.
>
> Michael
>
> > -----Original Message-----
> > From: pgsql-performance-owner(at)postgresql(dot)org
> > [mailto:pgsql-performance-owner(at)postgresql(dot)org]On Behalf Of Howard
> > Oblowitz
> > Sent: Tuesday, July 01, 2003 3:06 PM
> > To: pgsql-performance(at)postgresql(dot)org
> > Subject: FW: [PERFORM] Version 7 question
> >
> >
> > What would be the best value range for effective_cache_size
> > on Postgres 7.3.2, assuming say 1.5 GB of RAM and
> > shared_buffers set to 8192, and shmmax set to 750mb?
> >
> > And what are the most important factors one should take
> > into account in determining the value?
> >
> >
> >
> > > -----Original Message-----
> > > From: scott.marlowe [SMTP:scott(dot)marlowe(at)ihs(dot)com]
> > > Sent: 01 July 2003 02:56
> > > To: Michael Mattox
> > > Cc: Hilary Forbes; pgsql-performance(at)postgresql(dot)org
> > > Subject: Re: [PERFORM] Version 7 question
> > >
> > > 8192 is only 64 megs of RAM, not much, but a good number. Keep in mind
> > > that the kernel tends to be better at buffering huge amounts of disk,
> > > while postgresql is better left to use buffers that are large
> > enough for
> > > the current working set (i.e. not your whole database, just the largest
> > > amount of data you're slinging about on a regular basis in one query.)
> > >
> > > On a machine with 1.5 gig of RAM, I've found settings as high as 32768
> > > (256 megs of ram) to run well, but anything over that doesn't help. Of
> > > course, we don't toss around more than a hundred meg or so at a
> > time. If
> > >
> > > our result sets were in the gigabyte range, I'd A: want more
> > memory and B:
> > >
> > > Give more of it to postgresql.
> > >
> > > The original poster was, I believe running 7.0.x, which is way
> > old, so no,
> > >
> > > I don't think there was an equivalent of effective_cache_size in that
> > > version. Upgrading would be far easier than performance tuning
> > 7.0. since
> > >
> > > the query planner was much simpler (i.e. more prone to make bad
> > decisions)
> > >
> > > in 7.0.
> > >
> > > On Tue, 1 Jul 2003, Michael Mattox wrote:
> > >
> > > > I have my shared buffers at 8192 and my effective cache at
> > 64000 (which
> > > is
> > > > 500 megs). Depends a lot on how much RAM you have. I have
> > 1.5 gigs and
> > > > I've been asking my boss for another 512megs for over a month now. I
> > > have
> > > > no idea if my buffers are too high/low.
> > > >
> > > > Michael
> > > >
> > > > > -----Original Message-----
> > > > > From: pgsql-performance-owner(at)postgresql(dot)org
> > > > > [mailto:pgsql-performance-owner(at)postgresql(dot)org]On Behalf Of Hilary
> > > > > Forbes
> > > > > Sent: Tuesday, July 01, 2003 2:10 PM
> > > > > To: pgsql-performance(at)postgresql(dot)org
> > > > > Subject: [PERFORM] Version 7 question
> > > > >
> > > > >
> > > > > I'm just trying to improve performance on version 7 before doing
> > > > > some tests and hopefully upgrading to 7.3.
> > > > >
> > > > > At the moment we have
> > > > > B=64 (no of shared buffers)
> > > > > N=32 (no of connections)
> > > > > in postmaster.opt which I take it is the equivalent of the new
> > > > > postgresql.conf file.
> > > > >
> > > > > From all that is being written about later versions I suspect
> > > > > that this is far too low. Would I be fairly safe in making the
> > > > > no of shared buffers larger? Also is there an equivalent of
> > > > > effective_cache_size that I can set for version 7?
> > > > >
> > > > > Many thanks in advance
> > > > > Hilary
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hilary Forbes
> > > > > -------------
> > > > > DMR Computer Limited: http://www.dmr.co.uk/
> > > > > Direct line: 01689 889950
> > > > > Switchboard: (44) 1689 860000 Fax: (44) 1689 860330
> > > > > E-mail: hforbes(at)dmr(dot)co(dot)uk
> > > > >
> > > > > **********************************************************
> > > > >
> > > > >
> > > > > ---------------------------(end of
> > > broadcast)---------------------------
> > > > > TIP 5: Have you checked our extensive FAQ?
> > > > >
> > > > > http://www.postgresql.org/docs/faqs/FAQ.html
> > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------(end of
> > broadcast)---------------------------
> > > > TIP 5: Have you checked our extensive FAQ?
> > > >
> > > > http://www.postgresql.org/docs/faqs/FAQ.html
> > > >
> > >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: Have you searched our list archives?
> > >
> > > http://archives.postgresql.org
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> > (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>