Re: VACUUM optimization ideas.

> Here's two ideas I had for optimizing vacuum, I apologize in advance
> if the ideas presented here are niave and don't take into account
> the actual code that makes up postgresql.
> 
> ================
> 
> #1
> 
> Reducing the time vacuum must hold an exlusive lock on a table:
> 
> The idea is that since rows are marked deleted it's ok for the
> vacuum to fill them with data from the tail of the table as
> long as no transaction is in progress that has started before
> the row was deleted.
> 
> This may allow the vacuum process to copyback all the data without
> a lock, when all the copying is done it then aquires an exlusive lock
> and does this:
> 
> Aquire an exclusive lock.
> Walk all the deleted data marking it as current.
> Truncate the table.
> Release the lock.
> 
> Since the data is still marked invalid (right?) even if valid data
> is copied into the space it should be ignored as long as there's no
> transaction occurring that started before the data was invalidated.

Added to TODO:

* Reduce VACUUM lock time by moving tuples with read lock, then write  lock and truncate table [vacuum]  

The read-lock is required because other transactions must be prevented
from modifying the rows, and the index is also an issue.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026