On 07/07/2011 04:30 PM, D C wrote:
autovacuum_naptime = 30s
autovacuum_vacuum_threshold = 200
autovacuum_vacuum_scale_factor = 0.5
autovacuum_vacuum_cost_delay = 10
These are slightly strange settings. How did you come up with them?
The autovacuum_vacuum_scale_factor being so high is parti
On Thu, Jul 7, 2011 at 2:30 PM, D C wrote:
> Hello,
>
> (Apologies for any possible duplication of this email.)
>
> (Also, apologies if this is an obvious question. I have gone through the
> archives without seeing something that directly ties to this.)
>
> We are running Postgresql on a 64b RHEL
Hello,
(Apologies for any possible duplication of this email.)
(Also, apologies if this is an obvious question. I have gone through the
archives without seeing something that directly ties to this.)
We are running Postgresql on a 64b RHEL5.2 64b server. "Uname -a":
--Linux xx
On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
> Hi,
>
> I have a delete query taking 7.2G of ram (and counting) but I do not
> understant why so much memory is necessary. The server has 12G, and
> I'm afraid it'll go into swap. Using postgres 8.3.14.
>
> I'm purging some old data from
Is there any guidelines to sizing work_mem, shared_bufferes and other
configuration parameters etc., with regards to very large records? I
have a table that has a bytea column and I am told that some of these
columns contain over 400MB of data. I am having a problem on several
servers reading and
Hi,
I have a delete query taking 7.2G of ram (and counting) but I do not
understant why so much memory is necessary. The server has 12G, and
I'm afraid it'll go into swap. Using postgres 8.3.14.
I'm purging some old data from table t1, which should cascade-delete
referencing rows in t2. Here's an
Thanks all for your help. It is really useful, I will modify the query and
post the result.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/100-CPU-Utilization-when-we-run-queries-tp4465765p4560941.html
Sent from the PostgreSQL - performance mailing list archive at Nabble
On Wed, Jul 6, 2011 at 9:04 PM, Tomas Vondra wrote:
> Dne 6.7.2011 15:30, bakkiya napsal(a):
>> Any help, please?
>
> According to the EXPLAIN ANALYZE output (please, don't post it to the
> mailing list directly - use something like explain.depesz.com, I've done
> that for you this time: http://ex
On 07/05/2011 07:26 PM, Clem Dickey wrote:
Updates after belatedly reading the "slow queries" guidelines:
Version: PostgreSQL 8.4.8 on x86_64-redhat-linux-gnu, compiled by GCC
gcc (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2), 64-bit
The query has always been slow; the table for this test case is ne
