Horton

Re: Parallel bitmap heap scan

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-28T02:49:02Z
Lists: 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

Commits

  1. Pass DSA_ALLOC_HUGE when allocating a shared TIDBitmap.

  2. Support parallel bitmap heap scans.

  3. tidbitmap: Support shared iteration.

  4. Shut down Gather's children before shutting down Gather itself.

  5. Revise the way the element allocator for a simplehash is specified.

  6. Refactor bitmap heap scan estimation of heap pages fetched.

  7. Use more efficient hashtable for tidbitmap.c to speed up bitmap scans.