Re: [HACKERS] modeling parallel contention (was: Parallel Appendimplementation) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] modeling parallel contention (was: Parallel Appendimplementation)
Date
Msg-id 20170505024533.mtabemphwjx2osmh@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] modeling parallel contention (was: Parallel Appendimplementation)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2017-05-05 14:40:43 +1200, David Rowley wrote:
> On 5 May 2017 at 14:36, Andres Freund <andres@anarazel.de> wrote:
> > I wonder how much doing the atomic ops approach alone can help, that
> > doesn't have the issue that the work might be unevenly distributed
> > between pages.
> 
> I wondered that too, since I though the barrier for making this change
> would be lower by doing it that way.
> 
> I didn't manage to think of a way to get around the wrapping the
> position back to 0 when synch-scans are involved.
> 
> i.e
> parallel_scan->phs_cblock++;
> if (parallel_scan->phs_cblock >= scan->rs_nblocks)
> parallel_scan->phs_cblock = 0;

Increment phs_cblock without checking rs_nblocks, but outside of the
lock do a % scan->rs_nblocks, to get the "actual" position.  Finish if
(phs_cblock - phs_startblock) / scan->rs_nblocks >= 1.

The difficult part seems to be the parallel_scan->phs_startblock
computation, but that we probably can do via an read barrier & unlocked
check, and then a spinlock & recheck if still uninitialized.

- Andres



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] modeling parallel contention (was: Parallel Appendimplementation)