Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
I'm not sure how pg_class.relpages is maintained but what happens to a
bloated table? For example, a 100 row table that is constantly updated
and hasn't been vacuumed in a while (say the admin disabled autovacuum
for a while), now that small 100 row table has 1000 pages in it most of
which are just bloat, will we miss this table? Perhaps basing this on
reltuples would be better?
Well, this would only happen the first time, until the plain worker
processed the table; next time it would be picked up by the hot table
worker. But yeah, we can build a better estimate using the same trick
the planner uses: estimate tuple density as reltuples/relpages times the
actual number of blocks on disk.
Well even skipping it the first time isn't good, anything that further
delays a hot table from getting vacuumed is bad. Also, I'm not sure it
would just be the first time since plain VACUUM isn't going to reclaim
most of the space, just mark it as reusable. This is moot however if we
use a good metric, I have no idea if what you suggest above would be
good enough.
A table over 600 pages does not sound like a good candidate for hot, so
this seems more or less reasonable to me. On the other hand, maybe we
shouldn't tie this to the vacuum cost delay stuff.
I'm not sure it's a good idea to tie this to the vacuum cost delay
settings either, so let me as you this, how is this better than just
allowing the admin to set a new GUC variable like
autovacuum_hot_table_size_threshold (or something shorter) which we can
assign a decent default of say 8MB.
Yeah, maybe that's better -- it's certainly simpler.
Simple is better, at least until proven otherwise.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
