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
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 |