Shridhar Daithankar wrote:
> I agree, specifying per table thresholds would be good in autovacuum..
Which begs the question of what the future direction is for pg_autovacuum.
There would be some merit to having pg_autovacuum throw in some tables
in which to store persistent information, and at that point, it would
make sense to add some flags to support the respective notions that:
-> Some tables should _never_ be touched;
-> Some tables might get "reset" to indicate that they should be
considered as having been recently vacuumed, or perhaps that they
badly need vacuuming;
-> As you suggest, per-table thresholds;
-> pg_autovacuum would know when tables were last vacuumed by
it...
-> You could record vacuum times to tell pg_autovacuum that you
vacuumed something "behind its back."
-> If the system queued up proposed vacuums by having a "queue"
table, you could request that pg_autovacuum do a vacuum on a
particular table at the next opportunity.
All well and interesting stuff that could be worth implementing.
But the usual talk has been about ultimately integrating the
functionality into the backend, making it fairly futile to enhance
pg_autovacuum terribly much.
Unfortunately, the "integrate into the backend" thing has long seemed
"just around the corner." I think we should either:
a) Decide to enhance pg_autovacuum, or
b) Not.
In view of how long the "better answers" seem to be taking to emerge,
I think it makes sense to add functionality to pg_autovacuum.
--
output = reverse("ofni.smrytrebil" "@" "enworbbc")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
