Re: Parallel bitmap heap scan

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel bitmap heap scan
Date: 2016-11-27 02:34:09
Message-ID: CAFiTN-sCb7BL=qHm6+0PxOkr2Q0K0qu7r8aHAmThqoFmqVSJzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 27, 2016 at 3:15 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-11-27 03:49:06 Re: UNDO and in-place update
Previous Message David Fetter 2016-11-27 00:16:48 pg_config --version