Re: Autovacuum in the backend

Russell Smith wrote:

>On Fri, 17 Jun 2005 06:26 pm, Andreas Pflug wrote:
>  
>
>>Qingqing Zhou wrote:
>>    
>>
>>>One reason of not using lib-pq is that this one has to wait for the
>>>completion of each vacuum (we don't has async execution in libpq right?),
>>>      
>>>
>>There *is* async execution in libpq, and it works.
>>    
>>
>
>I would have thought the main reasons for not using libpq means you are locked
>into only using commands that are available to all users via SQL.  If you don't use
>libpq, you open up the ability to use functions that can make use of information available
>to the backend, and to also run functions in a way that it is not possible to do via SQL.
>

Right now we don't really want to fire off more than one VACUUM at a 
time since it will create a more substantial IO storm issue than we 
already have with vacuum.  Perhaps with the introduction of vacuum delay 
settings and table spaces we could / should rethink this, but for now 
it's the easiest way to go.

As for the standard SQL issue, FSM data (or anything else we might want) 
could be exported via regular SQL via some type of super-user only 
system function.  So that isn't really the issue.  I don't remember all 
the details but you can look at the discussion when my patch was 
rejected (around July of 2004).  People just didn't like including libpq 
into the backend for reasons I don't remember.  I don't *think* this is 
up for discussion, I *think* autovacuum has to work without libpq if it 
is going to be accepted.

Matthew