| From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: The max value of autovacuum_vacuum/analyze_scale_factor. |
| Date: | 2016-12-05 12:15:17 |
| Message-ID: | CAFjFpRcEyZMCNgTh5DLLguVkFyk8HdhjZ2uwMdxFNEnos7DkAA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 5, 2016 at 4:44 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> Hi all,
>
> Is there any reason why the max values of
> autovacuum_vacuum/analyze_scale_factor are 100.0? These max values are
> defined since when the parameters has been introduced but I think that
> 1.0 is enough.
>
Yes, at least from
https://www.postgresql.org/docs/devel/static/runtime-config-autovacuum.html,
it looks like this is supposed to be a "fraction of table size".
anything higher than 1.0 isn't a fraction. If at all any value > 1.0
has a meaning, I am wondering whether it's to account for bloat. But
then who would want to place the threashold in bloated area.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-12-05 12:18:55 | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. |
| Previous Message | Michael Paquier | 2016-12-05 12:07:59 | Re: Random number generation, take two |