On Oct 11, 2005, at 10:54 AM, Claus Guttesen wrote:
Thank you for your reply. Does this apply to FreeBSD 5.4 or 6.0 on
amd64 (or both)?
It applies to FreeBSD >= 5.0.
However, I have not been able to get a real answer from the FreeBSD
hacker community on what the max buffer space usage will
> > > Apparently this formula is no longer relevant on the FreeBSD systems as
> > > it can cache up to almost all the available RAM. With 4GB of RAM, one
> > > could specify most of the RAM as being available for caching, assuming
> > > that nothing but PostgreSQL runs on the server -- certainly 1/
On Tue, 2005-10-11 at 16:54 +0200, Claus Guttesen wrote:
> > > I have a postgresql 7.4.8-server with 4 GB ram.
> > > #effective_cache_size = 1000# typically 8KB each
> > >
> > > This is computed by sysctl -n vfs.hibufspace / 8192 (on FreeBSD). So I
> > > changed it to:
> > >
> > > effective_cac
> > I have a postgresql 7.4.8-server with 4 GB ram.
> > #effective_cache_size = 1000# typically 8KB each
> >
> > This is computed by sysctl -n vfs.hibufspace / 8192 (on FreeBSD). So I
> > changed it to:
> >
> > effective_cache_size = 27462# typically 8KB each
>
> Apparently this formula is
On 17 Sep 2003 at 11:48, Nick Barr wrote:
> Hi,
>
> I have been following a thread on this list "Inconsistent performance"
> and had a few questions especially the bits about effective_cache_size.
> I have read some of the docs, and some other threads on this setting,
> and it seems to used by th
Hi,
I have been following a thread on this list "Inconsistent performance"
and had a few questions especially the bits about effective_cache_size.
I have read some of the docs, and some other threads on this setting,
and it seems to used by the planner to either choose a sequential or
index scan.
On 1 Jul 2003 at 15:50, Howard Oblowitz wrote:
> The documentation says that Effective Cache Size "sets the optimizer's
> assumption
> about the effective size of the disk cache ( that is, the portion of the
> kernel's disk
> cache that will be used for PostgreSQL data files ).
>
> What then wil
On Tue, 1 Jul 2003 15:50:14 +0200 , Howard Oblowitz
<[EMAIL PROTECTED]> wrote:
>What then will be the effect of setting this too high?
The planner might choose an index scan where a sequential scan would
be faster.
>And too low?
The planner might choose a sequential scan where an index scan woul
Good questions. Basically, telling postgresql it has a larger disk cache
makes it favor index operations, smaller makes it favor seq scans.
If your machine has super fast I/O then you may want it to favor seq
scans, whereas if you have more CPU power than I/O bandwidth then you'd
likely want i
Thanks.
Some theoretical questions.
The documentation says that Effective Cache Size "sets the optimizer's
assumption
about the effective size of the disk cache ( that is, the portion of the
kernel's disk
cache that will be used for PostgreSQL data files ).
What then will be the effect of setti
10 matches
Mail list logo
