On Sun, Nov 27, 2016 at 3:15 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers