Horton

Re: [HACKERS] Autovacuum Improvements

Kenneth Marshall <ktm@it.is.rice.edu>

View thread
From: Kenneth Marshall <ktm@it.is.rice.edu>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Bruce Momjian <bruce@momjian.us>, Gregory Stark <stark@enterprisedb.com>, Heikki Linnakangas <heikki@enterprisedb.com>, Russell Smith <mr-russ@pws.com.au>, Darcy Buskermolen <darcyb@commandprompt.com>, Alvaro Herrera <alvherre@commandprompt.com>, "Matthew T. O'Connor" <matthew@zeut.net>, Pavan Deolasee <pavan@enterprisedb.com>, Christopher Browne <cbbrowne@acm.org>, pgsql-general@postgresql.org, pgsql-hackers@postgresql.org
Date: 2007-01-22T19:00:34Z
Lists: pgsql-hackers 
On Mon, Jan 22, 2007 at 06:42:09PM +0000, Simon Riggs wrote:
> On Mon, 2007-01-22 at 13:27 -0500, Bruce Momjian wrote:
> > Yep, agreed on the random I/O issue.  The larger question is if you have
> > a huge table, do you care to reclaim 3% of the table size, rather than
> > just vacuum it when it gets to 10% dirty?  I realize the vacuum is going
> > to take a lot of time, but vacuuming to relaim 3% three times seems like
> > it is going to be more expensive than just vacuuming the 10% once.  And
> > vacuuming to reclaim 1% ten times seems even more expensive.  The
> > partial vacuum idea is starting to look like a loser to me again.
> 
> Hold that thought! Read Heikki's Piggyback VACUUM idea on new thread...
> 
> -- 
>   Simon Riggs             
>   EnterpriseDB   http://www.enterprisedb.com
> 

There may be other functions that could leverage a similar sort of
infrastructure. For example, a long DB mining query could be registered
with the system. Then as the pieces of the table/database are brought in
to shared memory during the normal daily DB activity they can be acquired
without forcing the DB to run a very I/O expensive query when waiting a
bit for the results would be acceptable. As long as we are thinking
piggyback.

Ken