On Sunday 06 Jul 2003 5:54 am, Martin Foster wrote:
> The only time that I have ever seen load averages of 30 or more under
> OpenBSD is when one of my scripts goes wild.However, I can say that
> I am also seeing these load averages under PostgreSQL 7.3.2 after a
> migration to it from MySQL.
[
On 5 Jul 2003 at 22:54, Martin Foster wrote:
> What I would like to know is. Why? The kernel has been compiled to
> handle the number of concurrent connections, the server may not be the
> best, but it should be able to handle the requests: PIII 1Ghz, 1GB
> SDRAM, 2 IDE 20GB drives.
>
> I h
Shridhar Daithankar wrote:
On 5 Jul 2003 at 22:54, Martin Foster wrote:
What I would like to know is. Why? The kernel has been compiled to
handle the number of concurrent connections, the server may not be the
best, but it should be able to handle the requests: PIII 1Ghz, 1GB
SDRAM, 2 IDE
Richard Huxton wrote:
On Sunday 06 Jul 2003 5:54 am, Martin Foster wrote:
The only time that I have ever seen load averages of 30 or more under
OpenBSD is when one of my scripts goes wild.However, I can say that
I am also seeing these load averages under PostgreSQL 7.3.2 after a
migration to
On Sunday 06 July 2003 15:56, Martin Foster wrote:
> effective_cache_size seems interesting, though the description is
> somewhat lacking. Is this related to the swap partition and how much of
> it will be used by PostgreSQL? If I am correct, this should be fairly
> low? Martin Foster
It gives
Hi all,
In addition to Tom's patch, this patch asks tuning parameters right away,
while doing initdb. I have also changed the notice displayed after initdb is
done.
Just an attempt to make defaults user friendly. I would also like to add other
paramters to this approach, like fsync and random_
Martin Foster <[EMAIL PROTECTED]> writes:
>> The only time that I have ever seen load averages of 30 or more under
>> OpenBSD is when one of my scripts goes wild.
Note also that "high load average" is not per se an indication that
anything is wrong. In Postgres, if you have thirty queries waiting
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> In addition to Tom's patch, this patch asks tuning parameters right away,
> while doing initdb.
Sorry, there is zero chance of putting any interactivity into initdb.
Most RPM installations run it from the RPM install script and would be
unable to
Shridhar Daithankar wrote:
It gives hint to psotgresql how much file system cache is available in the
system.
You have 1GB memory and your application requirement does not exceed 400MB. So
OS can use roughly 600MB for file system cache. In that case you can set this
parameter to 400MB cache to
Tom Lane wrote:
Martin Foster <[EMAIL PROTECTED]> writes:
The only time that I have ever seen load averages of 30 or more under
OpenBSD is when one of my scripts goes wild.
Note also that "high load average" is not per se an indication that
anything is wrong. In Postgres, if you have thirty qu
>
> Brian Suggests:
> > I'm curious how many of the configuration values can be determined
> > automatically, or with the help of some script. It seem like there
> > could be some perl script in contrib that could help figure this out.
> > Possibly you are asked a bunch of questions and then the
> > This sort of narrative belongs in the SGML docs, not in a CONF file.
> > In fact, one could argue that we should take *all* commentary out of
> > the CONF file in order to force people to read the docs.
>
> The SGML docs aren't in the DBA's face and are way out of the way for
> DBAs rolling ou
On Sun, 6 Jul 2003, Matthew Nuzum wrote:
> At the very least, if there is good documentation for these parameters,
> maybe the conf file should provide a link to this info.
I believe that is what Josh is proposing:
http://archives.postgresql.org/pgsql-performance/2003-07/msg00102.php
> [Apache
Michael Pohl wrote:
On Sun, 6 Jul 2003, Matthew Nuzum wrote:
At the very least, if there is good documentation for these parameters,
maybe the conf file should provide a link to this info.
I believe that is what Josh is proposing:
http://archives.postgresql.org/pgsql-performance/2003-07/msg00
Richard Huxton wrote:
I don't know the *BSDs myself, but do you have the equivalent of iostat/vmstat
output you could get for us? Also a snapshot of "top" output? People are
going to want to see:
- overall memory usage (free/buffers/cache/swap)
- memory usage per process
- disk activity (block
15 matches
Mail list logo
