Re: Re: issue log message to suggest VACUUM FULL if a table is nearly empty - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: issue log message to suggest VACUUM FULL if a table is nearly empty
Date
Msg-id 11000.1405338934@sss.pgh.pa.us
Whole thread Raw
In response to Re: issue log message to suggest VACUUM FULL if a table is nearly empty  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: Re: issue log message to suggest VACUUM FULL if a table is nearly empty
List pgsql-hackers
Abhijit Menon-Sen <ams@2ndQuadrant.com> writes:
> Do we have any consensus on this patch?

> I took a quick look at it because no review was posted. The patch itself
> does what it claims to, but from the discussion it doesn't seem like we
> want the feature; or perhaps we only don't want it in its present form.

Re-reading the thread quickly, it seemed like there was considerable
pushback about the cost of collecting the stats, and worries about whether
it wouldn't just be log spam.  But I think the opposite of the latter
concern is also valid, namely that people who could benefit from the
warning are not going to see it because they don't peruse the postmaster
log carefully/at all.  That's a generic problem for warning messages
emitted by background tasks, which we ought to think about how to fix.
In the meantime though it seems like this patch is far more likely to be
annoying than helpful.

> So which is more appropriate, returned with feedback or rejected?
> (In the latter case, the TODO item should also be removed.)

I'd vote for rejecting and annotating the TODO item with a link to
this thread.  And maybe taking off the "easy" notation.  I think the
TODO item is reflecting a real usability issue, but solving it usefully
is quite a bit harder than it looks.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Incorrect comment in postgres_fdw.c
Next
From: Fujii Masao
Date:
Subject: Re: No exact/lossy block information in EXPLAIN ANALYZE for a bitmap heap scan