Horton

Re: Parallel bitmap heap scan

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-26T21:45:22Z
Lists: pgsql-hackers 
On Sat, Nov 26, 2016 at 7:40 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> IMHO, barrier is used when multiple worker are doing some work
> together in phase1, and before moving to next phase all have to
> complete phase1, so we put barrier, so that before starting next phase
> all cross the barrier.
>
> But here case is different, only one worker need to finish the phase1,
> and as soon as it's over all can start phase2. But we don't have
> requirement that all worker should cross certain barrier. In this case
> even though some worker did not start, other worker can do their work.

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

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.