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