[PERFORM] Some very weird behaviour....

2003-07-09 Thread Chris Bowlby
Hi All, I'm sure some of you know me from previous questions on other lists, but this one has myself and Marc completely stumped. We've got a database that has about 89 Million rows, under PostgreSQL 7.3.3 on a dual PIII 1.2 with 4 GBytes of RAM on a 5 disk RAID 5 array. The dataset itself is

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-09 Thread Kaarel
Are you willing to say that the PostgreSQL database system should only be used by DBAs? I believe that Postgres is such a good and useful tool that anyone should be able to start using it with little or no barrier to entry. I quite agree. But there is a difference between saying you should get

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-09 Thread scott.marlowe
On Wed, 9 Jul 2003, Kaarel wrote: Are you willing to say that the PostgreSQL database system should only be used by DBAs? I believe that Postgres is such a good and useful tool that anyone should be able to start using it with little or no barrier to entry. I quite agree. But there

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-09 Thread Martin Foster
Scott Marlowe wrote: It would be nice to have a program that could run on any OS postgresql runs on and could report on the current limits of the kernel, and make recommendations for changes the admin might want to make. One could probably make a good stab at effective cache size during

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-09 Thread Sean Chittenden
I don't have much to add because I'm pretty new to Postgres and have been soliciting advice here recently, but I totally agree with everything you said. I don't mind if it's in the postgres.conf file or in a faq that is easy to find, I just would like it to be in one place. A good example

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-09 Thread Martin Foster
Sean Chittenden wrote: I looked through the src/doc/runtime.sgml for a good place to stick this and couldn't find a place that this seemed appropriate, but on FreeBSD, this can be determined with a great deal of precision in a programmatic manner: echo effective_cache_size = $((`sysctl -n

[PERFORM] plpgsql vs. SQL performance (again)

2003-07-09 Thread Michael Pohl
About a month ago I asked the general list about plpgsql functions that occasionally significantly underperform their straight SQL equivalents. Tom noted that a different query plan was almost certainly being chosen by the plpgsql function:

Re: [NOVICE] [PERFORM] Extreme high load averages

2003-07-09 Thread Martin Foster
Dennis Björklund wrote: On Sun, 6 Jul 2003, Martin Foster wrote: The processor seems to be purposely sitting there twiddling it's thumbs. Which leads me to believe that perhaps the nice levels have to be changed on the server itself? It could also be all the usual things that affect