From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>, "pgsql-committers(at)lists(dot)postgresql(dot)org" <pgsql-committers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor |
Date: | 2019-04-15 08:23:05 |
Message-ID: | CAD21AoAWVKJ9YJrb8zGNuRoFB36M3n0r=4vNSVz+mbBFM6JMtg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Mon, Apr 15, 2019 at 11:57 AM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>
> Hi!
>
> On Sun, Apr 14, 2019 at 11:00 PM Piotr Stefaniak
> <postgres(at)piotr-stefaniak(dot)me> wrote:
> > On 26/06/2018 14.35, Alexander Korotkov wrote:
> > > Increase upper limit for vacuum_cleanup_index_scale_factor
> > >
> > > Upper limits for vacuum_cleanup_index_scale_factor GUC and reloption
> > > were initially set to 100.0 in 857f9c36. However, after further
> > > discussion, it appears that some users like to disable B-tree cleanup
> > > index scan completely (assuming there are no deleted pages).
> > >
> > > vacuum_cleanup_index_scale_factor is used barely to protect against
> > > stalled index statistics. And after detailed consideration it appears
> > > that risk of stalled index statistics is low. And it would be nice to
> > > allow advanced users setting higher values of
> > > vacuum_cleanup_index_scale_factor. So, set upper limit for these
> > > GUC and reloption to DBL_MAX.
> >
> > UB Sanitizer points out that prev_num_heap_tuples is sometimes 0,
> > leading to division by 0 in
> > (info->num_heap_tuples - prev_num_heap_tuples) /
> > prev_num_heap_tuples >= cleanup_scale_factor)
> > which are currently lines 839-840 in nbtree.c.
Thank you pointing out it.
> >
> > Attaching my idea of a fix.
>
> Thank you for noticing. BTW, I've more trivial idea for fixing this: replace
> prev_num_heap_tuples < 0
> with
> prev_num_heap_tuples <= 0
>
> If prev_num_heap_tuples == 0, subsequent part of expression isn't
> evaluated because result is known to be true. And I think it's right
> to don't skip cleanup when prev_num_heap_tuples == 0.
+1. It looks good to me.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2019-04-15 10:03:55 | pgsql: Fix thinko in ExecCleanupTupleRouting(). |
Previous Message | Peter Eisentraut | 2019-04-15 07:35:04 | pgsql: Unbreak index optimization for LIKE on bytea |