Re: Avoiding superfluous buffer locking during nbtree backwards scans
От | Masahiro Ikeda |
---|---|
Тема | Re: Avoiding superfluous buffer locking during nbtree backwards scans |
Дата | |
Msg-id | 639613b3dd64dd67ed20fdd55ded1408@oss.nttdata.com обсуждение исходный текст |
Ответ на | Avoiding superfluous buffer locking during nbtree backwards scans (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Avoiding superfluous buffer locking during nbtree backwards scans
|
Список | pgsql-hackers |
On 2024-11-08 07:42, Peter Geoghegan wrote: > Attached revision v2 pushes the fix further in this direction. It > explicitly documents that parallel _bt_readnextpage callers are > allowed to use their so->currPos state (including > blkno/nextPage/prevPage) to help _bt_readnextpage to decide whether it > can end the scan right away. However, parallel index scan callers > still won't be allowed to use this same so->currPos state to decide > what page to go to next -- _bt_readnextpage really will need to seize > the scan to get an authoritative blkno to make that part safe > (actually, one parallel scan _bt_readnextpage caller still seizes the > scan for itself, which is the one caller where _bt_readnextpage fully > trusts caller's blkno + lastcurrblkno). Thank you! I've confirmed that the v2 patch fixed the bug. As you mentioned, I also feel that the v2 patch is now easier to understand. Since I couldn't understand the reason, I have a question: is the following deletion related to this change? @@ -770,7 +785,7 @@ _bt_parallel_done(IndexScanDesc scan) /* * Should not mark parallel scan done when there's still a pending - * primitive index scan (defensive) + * primitive index scan */ Regards, -- Masahiro Ikeda NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: