Horton

Re: Parallel bitmap heap scan

Dilip Kumar <dilipbalaut@gmail.com>

View thread View on postgr.es
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-28T03:53:23Z
Lists: pgsql-hackers 
On Mon, Nov 28, 2016 at 9:20 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> 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!

+1


-- 
Regards,
Dilip Kumar
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.