Re: pg_autovacuum next steps

"Matthew T. O'Connor" <matthew(at)zeut(dot)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