Guillaume Cottenceau wrote:
I have noticed that others (Alvaro, Joshua) suggest to set
vacuum_cost_delay as low as 10 or 20 ms,
My suggestion is to set it as *high* as 10 or 20 ms. Compared to the
original default of 0ms. This is just because I'm lazy enough not to
have done any measuring of
Hi,
I'm currently trying to tune the Cost-Based Vacuum Delay in a
8.2.5 server. The aim is to reduce as much as possible the
performance impact of vacuums on application queries, with the
background idea of running autovacuum as much as possible[1].
My test involves vacuuming a large table, and
On Dec 7, 2007, at 4:50 AM, Guillaume Cottenceau wrote:
Hi,
I'm currently trying to tune the Cost-Based Vacuum Delay in a
8.2.5 server. The aim is to reduce as much as possible the
performance impact of vacuums on application queries, with the
background idea of running autovacuum as much as
On Dec 7, 2007, at 10:44 AM, Guillaume Cottenceau wrote:
Erik Jones erik 'at' myemma.com writes:
vacuum_cost_delay/vacuum_cost_limit (deactivated) 20/200
40/200 100/1000 150/1000 200/1000 300/1000
VACUUM ANALYZE time54 s112 s188
s109 s
Erik Jones erik 'at' myemma.com writes:
vacuum_cost_delay/vacuum_cost_limit (deactivated) 20/200
40/200 100/1000 150/1000 200/1000 300/1000
VACUUM ANALYZE time54 s112 s188
s109 s 152 s 190 s 274 s
SELECT time
On Tue, 2005-07-12 at 13:50 -0400, Ian Westmacott wrote:
It appears not to matter whether it is one of the tables
being written to that is ANALYZEd. I can ANALYZE an old,
quiescent table, or a system table and see this effect.
Can you confirm that this effect is still seen even when the
On Wed, 2005-07-13 at 11:55, Simon Riggs wrote:
On Tue, 2005-07-12 at 13:50 -0400, Ian Westmacott wrote:
It appears not to matter whether it is one of the tables
being written to that is ANALYZEd. I can ANALYZE an old,
quiescent table, or a system table and see this effect.
Can you
Ian Westmacott [EMAIL PROTECTED] writes:
On Wed, 2005-07-13 at 11:55, Simon Riggs wrote:
On Tue, 2005-07-12 at 13:50 -0400, Ian Westmacott wrote:
It appears not to matter whether it is one of the tables
being written to that is ANALYZEd. I can ANALYZE an old,
quiescent table, or a system
On Wed, 2005-07-13 at 14:58 -0400, Tom Lane wrote:
Ian Westmacott [EMAIL PROTECTED] writes:
On Wed, 2005-07-13 at 11:55, Simon Riggs wrote:
On Tue, 2005-07-12 at 13:50 -0400, Ian Westmacott wrote:
It appears not to matter whether it is one of the tables
being written to that is ANALYZEd.
I can at least report that the problem does not seem to
occur with Postgres 8.0.1 running on a dual Opteron.
--Ian
On Wed, 2005-07-13 at 16:39, Simon Riggs wrote:
On Wed, 2005-07-13 at 14:58 -0400, Tom Lane wrote:
Ian Westmacott [EMAIL PROTECTED] writes:
On Wed, 2005-07-13 at
On Mon, 2005-07-11 at 15:51 +0100, Simon Riggs wrote:
On Mon, 2005-07-11 at 09:07 -0400, Ian Westmacott wrote:
On Mon, 2005-07-11 at 07:31, Simon Riggs wrote:
The ANALYZE commands hold read locks on the tables you wish to write to.
If you slow them down, you merely slow down your write
On Tue, 2005-07-12 at 03:45, Simon Riggs wrote:
Since vacuum_cost_delay is a userset parameter, you should be able to
SET this solely for the analyze_thread. That way we will know with more
certainty that it is the analyze_thread that is interfering.
That is what I have been doing. In fact, I
On Fri, 2005-07-08 at 12:25 -0400, Ian Westmacott wrote:
I am beginning to look at Postgres 8, and am particularly
interested in cost-based vacuum/analyze. I'm hoping someone
can shed some light on the behavior I am seeing.
Suppose there are three threads:
writer_thread
every 1/15
On Mon, 2005-07-11 at 09:07 -0400, Ian Westmacott wrote:
On Mon, 2005-07-11 at 07:31, Simon Riggs wrote:
The ANALYZE commands hold read locks on the tables you wish to write to.
If you slow them down, you merely slow down your write transactions
also, and then the read transactions that
I am beginning to look at Postgres 8, and am particularly
interested in cost-based vacuum/analyze. I'm hoping someone
can shed some light on the behavior I am seeing.
Suppose there are three threads:
writer_thread
every 1/15 second do
BEGIN TRANSACTION
COPY table1 FROM stdin
Ian Westmacott [EMAIL PROTECTED] writes:
If I make the single configuration change of setting
vacuum_cost_delay=1000, each iteration in analyze_thread takes
much longer, of course. But what I also see is that the CPU
usage of the connections for writer_thread and reader_thread
spike up to
16 matches
Mail list logo
