From: | Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Masahiro(dot)Ikeda(at)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, Masao(dot)Fujii(at)nttdata(dot)com |
Subject: | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Date: | 2025-03-18 10:54:48 |
Message-ID: | 15991636-20c5-4333-85ee-2fc9e6c67049@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12.03.2025 23:50, Peter Geoghegan wrote:
> On Wed, Mar 12, 2025 at 4:28 PM Alena Rybakina
> <a(dot)rybakina(at)postgrespro(dot)ru> wrote:
>> Thank you for the explanation!
>>
>> Now I see why these changes were made.
>>
>> After your additional explanations, everything really became clear and I
>> fully agree with the current code regarding this part.
> Cool.
>
>> However I did not see an explanation to the commit regarding this place,
>> as well as a comment next to the assert and the parallel_aware check and
>> why BitmapIndexScanState was added in the ExecParallelReInitializeDSM.
> I added BitmapIndexScanState to the switch statement in
> ExecParallelReInitializeDSM because it is in the category of
> planstates that never need their shared memory reinitialized -- that's
> just how we represent such a plan state there.
>
> I think that this is supposed to serve as a kind of documentation,
> since it doesn't really affect how things behave. That is, it wouldn't
> actually affect anything if I had forgotten to add
> BitmapIndexScanState to the ExecParallelReInitializeDSM switch
> statement "case" that represents that it is in this "plan state
> category": the switch ends with catch-all "default: break;".
Agree.
>> In my opinion, there is not enough additional explanation about this in
>> the form of comments, although I think that it has already been
>> explained here enough for someone who will look at this code.
> What can be done to improve the situation? For example, would adding a
> comment next to the new assertions recently added to
> ExecIndexScanReInitializeDSM and ExecIndexOnlyScanReInitializeDSM be
> an improvement? And if so, what would the comment say?
>
After reviewing the logic again, I realized that I was confused
precisely in the reinitialization of memory for IndexScanState and
IndexOnlyScanState.
As far as I can see, either assert is not needed here, the functions
ExecIndexScanReInitializeDSM and ExecIndexScanReInitializeDSM can be
called only if parallel_aware is positive, or it makes sense that
reinitialization is needed only if parallel_aware is positive, then the
condition noted above is not needed. According to your letter (0), the
check should be removed there too, but I got confused in the comment. We
do not need to reinitialize memory because DSM is instrumentation state
only, but it turns out that we are reinitializing the memory, so we
don't do it at all?
I attached a diff file to the letter with the comment.
--
Regards,
Alena Rybakina
Postgres Professional
Attachment | Content-Type | Size |
---|---|---|
for_reinitialize_memory.diff.no-cfbot | text/plain | 946 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2025-03-18 10:55:25 | Re: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided. |
Previous Message | Jakub Wartak | 2025-03-18 10:51:47 | Re: BitmapHeapScan streaming read user and prelim refactoring |