Re: pg_autovacuum next steps

Tom Lane wrote:

>If you aren't a backend then you couldn't safely access shared memory,
>including FSM in particular. I see no reason you couldn't use GUC
>though. There is no "direct pipe connection" to the stats collector,
>except in the output direction which is not what you want, so I'm not
>seeing your point there.
>
>

I probably said that wrong, but how do backends get their stats data?
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. Someone earlier in the
thread seemed to imply there was a way to do this.

>I am not sure that lack of FSM access is a showstopper, though. We
>could easily imagine inventing backend commands to read out whatever
>info you want from FSM, so you could request the info from your
>connected backend.
>
>

Yeah I agree, and for phase 1 we can just continue working only on stats
data.

>The more I think about this the more I like it --- it keeps the autovac
>control code still at arms length from the backend which will surely
>ease development and experimentation. I suppose there is some overhead
>in pushing data back and forth over the FE/BE protocol, but surely that
>would be negligible next to the "real work" of vacuuming.
>

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.

Thanks again,

Matthew