Re: Parallel Seq Scan vs kernel read ahead

Em seg., 22 de jun. de 2020 às 23:29, David Rowley <dgrowleyml(at)gmail(dot)com>
escreveu:

> On Tue, 23 Jun 2020 at 07:33, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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.
>
> Just a short history lesson for Ranier to help clear up any confusion:
>
> Back before 3cda10f41 there was some merit in improving the
> performance of these functions. Before that, we used to dish out pages
> under a lock. With that old method, if given enough workers and a
> simple enough query, we could start to see workers waiting on the lock
> just to obtain the next block number they're to work on. After the
> atomics were added in that commit, we didn't really see that again.
>
It is a good explanation. I already imagined it could be to help other
processes, but I still wasn't sure.
However, I did a test with this modification (lock before retry), and it
worked.

>
> What we're trying to fix here is the I/O pattern that these functions
> induce and that's all we should be doing here. Changing this is
> tricky to get right as we need to consider so many operating systems
> and how they deal with I/O readahead.
>
Yes, I understand that focus here is I/O.

Sorry, by the noise.

regards,
Ranier Vilela