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
