Re: [HACKERS] GUC for cleanup indexes threshold. - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] GUC for cleanup indexes threshold.
Date
Msg-id CAPpHfdurk6Rh3vWKXojW1w=k7ay-h7YvW8XVL=a_Nkh+72dJeg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GUC for cleanup indexes threshold.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] GUC for cleanup indexes threshold.  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Re: [HACKERS] GUC for cleanup indexes threshold.  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Fri, Mar 9, 2018 at 3:12 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Fri, Mar 9, 2018 at 8:43 AM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> 2) These parameters are reset during btbulkdelete() and set during
> btvacuumcleanup().

Can't we set these parameters even during btbulkdelete()? By keeping
them up to date, we will able to avoid an unnecessary cleanup vacuums
even after index bulk-delete.
 
We certainly can update cleanup-related parameters during btbulkdelete().
However, in this case we would update B-tree meta-page during each
VACUUM cycle.  That may cause some overhead for non append-only
workloads.  I don't think this overhead would be sensible, because in
non append-only scenarios VACUUM typically writes much more of information.
But I would like this oriented to append-only workload patch to be
as harmless as possible for other workloads.

I've not reviewed the code deeply yet but the regression test of this
patch seems to wrongly pass the regression tests and bt_metap()
function of pageinspect needs to be updated.

Right.  Thank you for fixing this issue.
 
Attached an updated patch
fixed these issue. Will review the patch again.

Thank you!

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Failed to request an autovacuum work-item in silence
Next
From: Claudio Freire
Date:
Subject: Re: Faster inserts with mostly-monotonically increasing values