Re: Parallel bitmap heap scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel bitmap heap scan
Date
Msg-id CAA4eK1L5oKiTqNqi7LH4yAxiqdyL3GYF5+rttCpnqNHL-nVywQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel bitmap heap scan  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Parallel bitmap heap scan  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Mon, Nov 28, 2016 at 8:11 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> When a new participant arrives here, if it finds that we're still in
> the INIT phase, then it enters an election to see if it can build the
> bitmap; one lucky participant wins and does that, while any other
> participants twiddle their thumbs at the next BarrierWait call.  If  a
> new participant finds that we're already in the BUILDING phase when it
> arrives, then it has missed that election and just has to wait for the
> building to be completed.  Once they all agree that building has
> finished, we move onto scanning.  If a new arrival finds that we're in
> SCANNING phase, then it happily scans and emits tuples.  Does that
> make sense?
>
> Not sure exactly how to coordinate rescans yet, but probably with
> BarrierWaitSet(&something->barrier, PBS_PHASE_INIT).
>

Do you think that using barrier's will simplify the patch as compared
to using condition variables because in that case, it will make sense
to use barriers?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fixed pg_class refcache leak when the meta tuple in pg_class in invalid.
Next
From: Michael Paquier
Date:
Subject: Re: Autovacuum breakage from a734fd5d1