Re: Questions/Observations related to Gist vacuum

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Questions/Observations related to Gist vacuum
Date: 2019-10-21 09:27:58
Message-ID: 94FB5F8A-1EDB-4B1F-A4D6-DC4D1F2AD232@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 21 окт. 2019 г., в 11:12, Dilip Kumar <dilipbalaut(at)gmail(dot)com> написал(а):
>
> On Mon, Oct 21, 2019 at 2:30 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>>
>> 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?

Yes, you are right, sorry for the noise.
Currently we are doing both gistvacuumscan() and gistvacuum_delete_empty_pages() in both gistbulkdelete() and gistvacuumcleanup(). Is it supposed to be so? Functions gistbulkdelete() and gistvacuumcleanup() look very similar and share some comments. This is what triggered my attention.

Thanks!

--
Andrey Borodin
Open source RDBMS development team leader
Yandex.Cloud

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2019-10-21 09:41:23 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Amit Kapila 2019-10-21 09:20:14 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions