From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: [HACKERS] More stats about skipped vacuums |
Date: | 2017-11-26 00:59:19 |
Message-ID: | 8327.1511657959@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> I am not arguing about skipped vacuuum data here (don't think much of
> it by the way), but of the number of index scans done by the last
> vacuum or autovacuum. This helps in tunning autovacuum_work_mem and
> maintenance_work_mem. The bar is still too high for that?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2017-11-26 01:17:44 | Re: [HACKERS] PATCH: multivariate histograms and MCV lists |
Previous Message | Michael Paquier | 2017-11-25 23:51:53 | Re: [HACKERS] More stats about skipped vacuums |