Re: pg_autovacuum next steps

"Matthew T. O'Connor" <matthew@zeut.net> writes:
> Tom Lane wrote:
>> There is no "direct pipe connection" to the stats collector,

> I probably said that wrong, but how do backends get their stats data?  

They read it out of a flat file that the stats collector rewrites every
so often.

> Meaning, when I do a "select * from pg_stat_all_tables" how is the 
> backend getting that data.  The reason I'm interested is that if I don't 
> have to fire up a backend just to check the stats that would reduce the 
> load associated with the autovacuum daemon.

Is that really worth the loss of independence?  I'm not sure one way or
the other myself.  I suppose the autovac daemon could still be run by
hand for testing purposes, but it would have to run as user postgres and
on the same machine as the postmaster.

> Right, I think the overhead would be negligible.  Since you seem to 
> think this is (or at least might be) a good idea, I will go ahead and 
> try to get the postmaster to fire-up the autovacuum daemon.  So that the 
> 1st cut, will basically be pg_autovacuum exactly as it stands now,  just 
> launched by the postmaster.

> Also, you didn't mention if I will be able to use the backend logging 
> functions, I would guess that I can, but I'm not totally sure.

Yes, if you are launched by the postmaster then you'd have access to its
stderr etc, so you could just log via elog/ereport.  Again though this
puts you in a situation where the daemon *must* be launched by the
postmaster or it won't work.  How much arm's-length separation are you
willing to give up?
        regards, tom lane