Re: Parallel Seq Scan vs kernel read ahead

Em seg., 22 de jun. de 2020 às 16:33, Robert Haas <robertmhaas(at)gmail(dot)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(dot)vf(at)gmail(dot)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