| 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: | Whole Thread | Raw Message | 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 |