> This seems maybe a bit overkill to me. I think what would be more useful > is if autovacuum could execute more than one vacuum at a time, and you > could specify tables that are high priority (or possibly just say that > all tables with less than X live tuples in them are high priority). That > way a longer-running vacuum on a large table wouldn't prevent more > vacuum-sensative tables (such as queues) from being vacuumed frequently > enough. Actually, I can think of a case for much the opposite, namely to want to concurrently vacuum some LARGE tables... Suppose you have 2 rather big tables that get updates on similar schedules such that both will have a lot of dead tuples at similar times. And suppose both of these tables are Way Large, so that they take six hours to vacuum. I could argue for kicking off vacuums on both, at the same moment; they'll both be occupying transactions for 1/4 of a day, and, with possibly related patterns of updates, doing them one after the other *wouldn't* forcibly get you more tuples cleaned than doing them concurrently. I'm not sure that's a case to push for, either, as something pg_autovacuum is smart enough to handle; I'm just putting out some ideas that got enough internal discussion to suggest they were interesting enough to let others consider... -- "cbbrowne","@","gmail.com" http://cbbrowne.com/info/linuxdistributions.html "Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete strangers to kill again." -- Unknown, Marin County newspaper's TV listing for _The Wizard of Oz_
