Re: Auto Vacuum - Mailing list pgsql-hackers

Hello Russell,

Russell Smith wrote:

>I am doing serious thinking about the implementation of Auto Vacuum as part of the backend, Not using libpq, but
classinginternal functions directly.
 
>It appears to me that calling internal functions directly is a better implementation than using the external library
todo the job.
 
>
>  
>
We are planning to move it into the backend (no longer an external libpq 
based contrib module)  I tried to do this for 8.0, but it didn't make 
the cut, so I expect this work will be done for 8.1.

>I know I might be stepping on Matthew's toes, but I don't really want to.  I am a complete newbie to the postgresql
code,however I am trying.
 
>Vacuum appears to be one of the bigger saw points with administrator having to configure it via scheduled tasks.
>
>  
>
Agreed, that is one of the reasons I took on Autovacuum, I think it is 
something a lot of admins would like PG to do for itself.

>The major autovacuum issues 
>
>1. Transaction Wraparound
>2. Vacuum of relations
>3. Tracking of when to do vacuums
>4. Where to store information needed by auto vacuum
>
>1. Transaction Wraparound
>
>  
>
This is handled by the current autovacuum using the process outlined in:
http://www.postgresql.org/docs/7.4/static/maintenance.html

>2. Vacuuming of relations
>
>Currently, the entire heap must be vacuumed at one time.  I would possible be desireable to have only part of the
relationvacuumed at
 
>a time.  If you can find out which parts of the relation have the most slack space.  There is a todo item regarding
trackingrecent deletions
 
>so they can be resused.  Some form of this would be helpful to work out what to vacuum.  Performance issues for this
typeof activity 
 
>may be a concern.  But I have no experience to be able to make comment on them.  So I welcome yours.
>
>  
>
This is not really an autovacuum related topic, if at some point someone 
adds the ability to VACUUM to do partials then autovacuum will make use 
of it.  BTW, this has been suggested several times so please search the 
archives for details.

>3. Tracking of when to vacuum
>
>Current autovacuum relies the stats collector to be running.  I would like to only use the stats if they are
available,
>and have an option to be able to vacuum accurately without having to have stats running.
>  
>
I think it is universally agreed upon that using data from the FSM is a 
better solution since it would not require you to have the stats system 
running and actually gives you a very accurate picture of what table 
have slack space to recover (assuming that the FSM is large enough).  
This is a topic that I need help on from some more enlightened core hackers.

>4. Where to store information required by auto vacuum.
>  
>
The backend integration patch that I submitted a few months ago added a 
new pg_autovacuum table to the system catalogues.  This table stored 
data that pg_autovacuum needed to persist across backend restarts, and 
also allowed the user to set per table settings for thresholds etc.  I 
never heard anyone complain about this design, so from the silence I 
assume this is an acceptable way of maintaining pg_autovacuum related data.

Matthew