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

From Dilip Kumar
Subject Re: Parallel bitmap heap scan
Date
Msg-id CAFiTN-sCb7BL=qHm6+0PxOkr2Q0K0qu7r8aHAmThqoFmqVSJzQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel bitmap heap scan  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel bitmap heap scan
List pgsql-hackers
On Sun, Nov 27, 2016 at 3:15 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think the Barrier stuff has a process for choosing one worker to
> conduct a particular phase.  So it seems like if the Barrier API is
> well-designed, you should be able to use it to decide who will conduct
> the index scan, and then when that's done everyone can proceed to
> scanning the heap.  If that can't work for some reason, Thomas should
> probably adjust his API so it does.  He's presenting that as a
> generally-useful primitive...

If I understand the barrier API correctly, It has two Part.
1. BarrierInit  2. BarrierWait.

1. In BarrierInit we defined that, how many worker(lets say nworkers)
should cross the barrier, before we are allowed to cross the
BarriedWait.

2. BarrierWait, will actually make calling process wait until
BarrierWait is not called for nworkers times.

So I am not very clear, If we call BarrierInit with nworkers=1, then
first question is when should we call BarrierWait, because as soon as
we call BarrierWait count will reach 1, and now everyone is allowed to
proceed. so obviously It should be called once the Bitmap is Ready.

Second question is, if it's called only after Bitmap is ready, then
what about other process, how they are supposed to wait until bitmap
is not ready. If they wait using BarrierWait, it again make the count
1 and everyone is allowed to proceed. Which doesn't seems correct.

Correct me if I am missing something ?

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: pg_config --version
Next
From: Amit Kapila
Date:
Subject: Re: UNDO and in-place update