Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Well, if you issue a manual vacuum then you can argue that it has been
> "modified" (it's seeing some activity). But immediately after a vacuum
> the table will not be vacuumed by autovac if there's no other activity,
> because there's no need for it, so we can create the entry anyway and it
> won't make an immediate difference.
You're ignoring the point of this thread, which is that creating
hashtable entries for tables that aren't actively being modified
causes significant ongoing overhead that we ought to try to minimize.
What I'm suggesting is that only foreground modification activity
(insert/update/delete) should trigger creation of a hashtable entry.
Once that has happened, it's reasonable to update the entry after
any vacuum or analyze. But a vacuum or analyze shouldn't force an
entry to spring into existence when nothing else is happening to
the table. That just bloats the stats file.
Given the current autovac logic, ordinary autovac operations won't cause
useless entries to be created anyway ... but an anti-wraparound vacuum
will, and so will manual vacuum or analyze commands.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
