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
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
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
"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
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
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
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
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
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
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
10 matches
Mail list logo