Re: Questions/Observations related to Gist vacuum

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Questions/Observations related to Gist vacuum
Дата
Msg-id CAFiTN-vKY6ZXzqXd0gDzkUiotqraygciC6Rf2Yca=7fDL-3Y8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Questions/Observations related to Gist vacuum  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: Questions/Observations related to Gist vacuum  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список pgsql-hackers
On Mon, Oct 21, 2019 at 2:30 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> Hi!
>
> > 18 окт. 2019 г., в 13:21, Dilip Kumar <dilipbalaut@gmail.com> написал(а):
> >
> > On Fri, Oct 18, 2019 at 10:55 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >>
> >>
> >> I think we can do it in general as adding some check for parallel
> >> vacuum there will look bit hackish.
> > I agree with that point.
> > It is not clear if we get enough
> >> benefit by keeping it for cleanup phase of the index as discussed in
> >> emails above.  Heikki, others, let us know if you don't agree here.
> >
> > I have prepared a first version of the patch.  Currently, I am
> > performing an empty page deletion for all the cases.
>
> I've took a look into the patch, and cannot understand one simple thing...
> We should not call gistvacuum_delete_empty_pages() for same gist_stats twice.
> Another way once the function is called we should somehow update or zero empty_leaf_set.
> Does this invariant hold in your patch?
>
Thanks for looking into the patch.   With this patch now
GistBulkDeleteResult is local to single gistbulkdelete call or
gistvacuumcleanup.  So now we are not sharing GistBulkDeleteResult,
across the calls so I am not sure how it will be called twice for the
same gist_stats?  I might be missing something here?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: pglz performance
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions