Re: [HACKERS] GUC for cleanup indexes threshold.
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] GUC for cleanup indexes threshold. |
Дата | |
Msg-id | CAD21AoCCObzLUxSya-KWCrRChjVvAv6v34=dQDZQmr3gbYzOkw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GUC for cleanup indexes threshold. (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: [HACKERS] GUC for cleanup indexes threshold.
|
Список | pgsql-hackers |
On Sat, Mar 10, 2018 at 3:40 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > 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. What overhead are you referring here? I guess the overhead is only the calculating the oldest btpo.xact. And I think it would be harmless. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: