Kevin Grittner <kgri...@ymail.com> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I think that the minimum appropriate fix here is to revert the hunk
>> I quoted, ie take out the suppression of stats reporting and analysis.
> I'm not sure I understand -- are you proposing that is all we do
> for both the VACUUM command and autovacuum?
No, I said that was the minimum fix.
Looking again at the patch, I note this comment:
/*
+ * We failed to establish the lock in the specified number of
+ * retries. This means we give up truncating. Suppress the
+ * ANALYZE step. Doing an ANALYZE at this point will reset the
+ * dead_tuple_count in the stats collector, so we will not get
+ * called by the autovacuum launcher again to do the truncate.
+ */
and I suppose the rationale for suppressing the stats report was this
same idea of lying to the stats collector in order to encourage a new
vacuum attempt to happen right away. Now I'm not sure that that's a
good idea at all --- what's the reasoning for thinking the table will be
any less hot in thirty seconds? But if it is reasonable, we need a
redesign of the reporting messages, not just a hack to not tell the
stats collector what we did.
Are you saying you intend to revert that whole concept? That'd be
okay with me, I think. Otherwise we need some thought about how to
inform the stats collector what's really happening.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
