Re: Parallel Seq Scan vs kernel read ahead
| От | Ranier Vilela |
|---|---|
| Тема | Re: Parallel Seq Scan vs kernel read ahead |
| Дата | |
| Msg-id | CAEudQAoMBC4L0=h5RU1z05Q+W+LvyL14S5vCopWDyFF6wBufFQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel Seq Scan vs kernel read ahead (Robert Haas <robertmhaas@gmail.com>) |
| Список | 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.
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.
Ranier Vilela
Вложения
В списке pgsql-hackers по дате отправления: