[PERFORM] SQL Monitoring

2007-10-09 Thread Campbell, Lance
PGSQL 8.2.4 I have noticed a slight spike in the amount of CPU usage in the last few weeks. I am sure it has to do with a change or two that was made to some queries. What is the best way to log the SQL that is being executed? I would prefer to limit the size of the log file to 2 G. Is ther

Re: [PERFORM] SQL Monitoring

2007-10-09 Thread Marcin Stępnicki
On 10/9/07, Campbell, Lance <[EMAIL PROTECTED]> wrote: > I have noticed a slight spike in the amount of CPU usage in the last few > weeks. I am sure it has to do with a change or two that was made to some > queries. What is the best way to log the SQL that is being executed? I > would prefer to

Re: [PERFORM] SQL Monitoring

2007-10-09 Thread Heikki Linnakangas
Campbell, Lance wrote: > I have noticed a slight spike in the amount of CPU usage in the last few > weeks. I am sure it has to do with a change or two that was made to > some queries. What is the best way to log the SQL that is being > executed? Take a look at statement_timeout and log_stateme

Re: [PERFORM] SQL Monitoring

2007-10-09 Thread Gregory Stark
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Campbell, Lance wrote: >> I have noticed a slight spike in the amount of CPU usage in the last few >> weeks. I am sure it has to do with a change or two that was made to >> some queries. What is the best way to log the SQL that is being >> exec

[PERFORM] hashjoin chosen over 1000x faster plan

2007-10-09 Thread Kevin Grittner
I have a situation where a query is running much slower than I would expect. The ANALYZE showed that it is hashing some information which is rarely needed. When I set enable_hashjoin = off for the connection the query run in 1/1000 the time. This isn't a debilitating level of performance, but i

[PERFORM] Shared Buffer setting in postgresql.conf

2007-10-09 Thread Radhika S
Hi, Along with my previous message (slow postgres), I notice the shared buffer setting for our production database is set to 1000. How much higher can I go? I don't know how much my kernel can take? I am running postgres 7.4.6 on Redhat enterprise 3 server. Thanks, Radhika -- It is all a matte

Re: [PERFORM] Postgres running Very slowly

2007-10-09 Thread Bill Moran
In response to "Radhika S" <[EMAIL PROTECTED]>: > Hi -, > I have a very peculiar situation. > > I am running a postgres 7.4.6 database. It is running slow... . 7.4.6 is very old. You're lucky it hasn't corrupted your data. At least upgrade to the latest 7.4.18 (yes, that's 12 patches ahead

[PERFORM] Postgres running Very slowly

2007-10-09 Thread Radhika S
Hi -, I have a very peculiar situation. I am running a postgres 7.4.6 database. It is running slow... . I vacuum --analyze daily. I just did again. I did a vacuum full last night. But to no avail. CPU usage and memory are normal, but the system is crawling. Here is the info from vacuum. CPU

Re: [PERFORM] Shared Buffer setting in postgresql.conf

2007-10-09 Thread Marcin Stępnicki
On 10/9/07, Radhika S <[EMAIL PROTECTED]> wrote: > Hi, > Along with my previous message (slow postgres), I notice the shared buffer > setting for our production database is set to 1000. > How much higher can I go? I don't know how much my kernel can take? A lot higher. How much memory do you have

Re: [PERFORM] hashjoin chosen over 1000x faster plan

2007-10-09 Thread Simon Riggs
On Tue, 2007-10-09 at 15:09 -0500, Kevin Grittner wrote: > I have a situation where a query is running much slower than I would > expect. The ANALYZE showed that it is hashing some information which > is rarely needed. When I set enable_hashjoin = off for the > connection the query run in 1/1000