Skip site navigation (1) Skip section navigation (2)

Re: Is there a reason _not_ to vacuum continuously?

From: "Matt Clark" <matt(at)ymogen(dot)net>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Is there a reason _not_ to vacuum continuously?
Date: 2003-09-17 20:20:02
Message-ID: LFEIJBEOKGPDHCEMDGNFKECGCDAA.matt@ymogen.net (view raw or flat)
Thread:
Lists: pgsql-performance
Yes, that makes sense.  My worry is really the analyzes.  I gather/imagine
that:

1)	Indexes on fields that are essentially random gain little from being
analyzed.
2)	Fields that increase monotonically with insertion order have a problem
with index growth in 7.2.  There may be a performance issue connected with
this, although indexes on these fields also gain little from analysis.  So
if I can't vacuum full I'm SOL anyway and should upgrade to 7.4.1 when
available?

Further data:  When I run a vacuum analyze my app servers do see an increase
in response time from PG, even though the DB server is under no more
apparent load.  I can only assume some kind of locking issue.  Is that fair?

M





> -----Original Message-----
> From: pgsql-performance-owner(at)postgresql(dot)org
> [mailto:pgsql-performance-owner(at)postgresql(dot)org]On Behalf Of
> scott.marlowe
> Sent: 17 September 2003 20:55
> To: Matt Clark
> Cc: pgsql-performance(at)postgresql(dot)org
> Subject: Re: [PERFORM] Is there a reason _not_ to vacuum continuously?
>
>
> On Wed, 17 Sep 2003, Matt Clark wrote:
>
> > *** THE QUESTION(S) ***
> > Is there any reason for me not to run continuous sequential
> vacuum analyzes?
> > At least for the 6 tables that see a lot of updates?
> > I hear 10% of tuples updated as a good time to vac-an, but does
> my typical
> > count of 3 indexes per table affect that?
>
> Generally, the only time continuous vacuuming is a bad thing is when you
> are I/O bound.  If you are CPU bound, then continuous vacuuming
> is usually
> acceptable.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>


In response to

pgsql-performance by date

Next:From: Vivek KheraDate: 2003-09-17 20:21:46
Subject: Re: restore time: sort_mem vs. checkpoing_segments
Previous:From: Robert TreatDate: 2003-09-17 20:15:46
Subject: Re: restore time: sort_mem vs. checkpoing_segments

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group