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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > scott.marlowe > Sent: 17 September 2003 20:55 > To: Matt Clark > Cc: [EMAIL PROTECTED] > 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? http://archives.postgresql.org
