Horton

Re: Parallel bitmap heap scan

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.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-28T03:50:02Z
Lists: pgsql-hackers 
On Mon, Nov 28, 2016 at 3:49 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> 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?

It would work, but I suppose you might call it overkill.  If they were
cooperating to build the bitmap in parallel then a barrier might look
more tempting, because then they'd all be waiting for each other to
agree that they've all finished doing that and are ready to scan.
When they're all just waiting for one guy to flip a single bit, then
it's debatable whether a barrier is any simpler than a condition
variable + a spinlock + a bit!

-- 
Thomas Munro
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.