Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> - pg_statistic is completely ignored.
... pg_statistic still needs vacuuming, surely. It's only ANALYZE
that you can/should skip for it.
> - The postmaster's main loop sleeps Min(60, autovacuum_naptime), in
> order to be able to pick naptimes smaller than 60 seconds. In order
> not to make the loop a busy-wait, I forced a minimum of 1 to that GUC
> var.
Hmm, I wonder whether the minimum shouldn't be 10. Or even 60.
> - Now that we have a real Xid wraparound check, we could go back to
> having any table with no stat entry ignored, which was the original
> coding. There's no danger of wraparound, and there'd be no work done
> to a table that doesn't have any activity.
Agreed.
> We have to consider what
> happens at stat reset -- AFAICS there's no problem, because as soon as
> the table sees some activity, it will be picked up by pgstat.
> However, it would be bad if stats are reset right after some heavy
> activity on a table. Maybe the only thing we need is documentation.
What's the use-case for having the stat reset feature at all?
> - datallowcon is still ignored. Now it's safe to do so, because we have
> a real Xid wraparound check. Changing it requires extending the
> pg_database flat-file (should be fairly easy).
I think this is all right, as long as a database that shows no stats
traffic is only connected to when it needs to be vacuumed for XID wrap
prevention purposes.
> - There are stat messages emitted for a database-wide vacuum, just like
> any other. This means that all tables in the database would end up in
> pgstat; and also all databases, including those with datallowconn = false.
> This may not be good. I'm not sure what exactly to do about it. Do
> we want to disallow such stats? Disable message sending (or
> collecting) in some circumstances?
Needs thought...
regards, tom lane
