On Sun, Nov 26, 2017 at 9:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'd say so ... that's something the average user will never bother with,
> and even if they knew to bother, it's far from obvious what to do with
> the information. Besides, I don't think you could just save the number
> of scans and nothing else. For it to be meaningful, you'd at least have
> to know the prevailing work_mem setting and the number of dead tuples
> removed ... and then you'd need some info about your historical average
> and maximum number of dead tuples removed, so that you knew whether the
> last vacuum operation was at all representative. So this is sounding
> like quite a lot of new counters, in support of perhaps 0.1% of the
> user population. Most people are just going to set maintenance_work_mem
> as high as they can tolerate and call it good.
In all the PostgreSQL deployments I deal with, the database is
embedded with other things running in parallel and memory is something
that's shared between components, so being able to tune more precisely
any of the *_work_mem parameters has value (a couple of applications
are also doing autovacuum tuning at relation-level). Would you think
that it is acceptable to add the number of index scans that happened
with the verbose output then? Personally I could live with that
information. I recall as well a thread about complains that VACUUM
VERBOSE is showing already too much information, I cannot put my
finger on it specifically now though. With
autovacuum_log_min_duration, it is easy enough to trace a vacuum
pattern. The thing is that for now the tuning is not that evident, and
CPU cycles can be worth saving in some deployments while memory could
be extended more easily.
--
Michael