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
On Wed, Jul 6, 2011 at 9:04 PM, Tomas Vondra t...@fuzzy.cz 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:
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
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
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
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 table
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 xxx
On Thu, Jul 7, 2011 at 2:30 PM, D C ptrading...@gmail.com 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 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
