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 CAEudQApFR5yU09Txxt7czSjKhTJMUs9x5p=5HnZK+QubE=h5RQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan vs kernel read ahead  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
Em seg., 22 de jun. de 2020 às 23:29, David Rowley <dgrowleyml@gmail.com> escreveu:
On Tue, 23 Jun 2020 at 07:33, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: TAP tests and symlinks on Windows
Next
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Initial progress reporting for COPY command