Re: Parallel Seq Scan vs kernel read ahead - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Parallel Seq Scan vs kernel read ahead
Date
Msg-id CAEudQAoMBC4L0=h5RU1z05Q+W+LvyL14S5vCopWDyFF6wBufFQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan vs kernel read ahead  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Em seg., 22 de jun. de 2020 às 16:33, Robert Haas <robertmhaas@gmail.com> escreveu:
Ranier,

This topic is largely unrelated to the current thread. Also...
Weel, I was trying to improve the patch for the current thread.
Or perhaps, you are referring to something else, which I may not have understood.
 

On Mon, Jun 22, 2020 at 12:47 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
> Questions:
> 1. Why acquire and release lock in retry: loop.

This is a super-bad idea. Note the coding rule mentioned in spin.h.
There are many discussion on this mailing list about the importance of
keeping the critical section for a spinlock to a few instructions.
Calling another function that *itself acquires an LWLock* is
definitely not OK.
Perhaps, I was not clear and it is another misunderstanding.
I am not suggesting a function to acquire the lock.
By the way, I did the tests with this change and it worked perfectly.
But, as it is someone else's patch, I asked why to learn.
By the way, my suggestion is with less instructions than the patch.
The only change I asked is why to acquire and release the lock repeatedly within the goto retry, when you already have it.
If I can acquire the lock before retry: and release it only at the end when I leave table_block_parallelscan_startblock_init,
why not do it.
I will attach the suggested excerpt so that I have no doubts about what I am asking.
 
regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Default setting for enable_hashagg_disk
Next
From: Justin Pryzby
Date:
Subject: Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)