Re: Is there a reason _not_ to vacuum continuously?

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
>