Yes, that makes sense.  My worry is really the analyzes.  I gather/imagine

1)      Indexes on fields that are essentially random gain little from being
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

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?


> -----Original Message-----
> [mailto:[EMAIL PROTECTED] Behalf Of
> scott.marlowe
> Sent: 17 September 2003 20:55
> To: Matt Clark
> 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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to