Re: Parallel bitmap heap scan - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Parallel bitmap heap scan
Date
Msg-id 20161017201558.cr34stc6zvxy3mst@alap3.anarazel.de
Whole thread Raw
In response to Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
Hi,

On 2016-10-07 11:46:40 +0530, Dilip Kumar wrote:
> Brief design idea:
> -----------------------
> #1. Shared TIDBitmap creation and initialization
>   First worker to see the state as parallel bitmap info as PBM_INITIAL
> become leader and set the state to PBM_INPROGRESS All other   workers
> see the state as PBM_INPROGRESS will wait for leader to complete the
> TIDBitmap.
> 
> #2 At this level TIDBitmap is ready and all workers are awake.
> 
> #3. Bitmap processing (Iterate and process the pages).
> In this phase each worker will iterate over page and chunk array and
> select heap pages one by one. If prefetch is enable then there will be
> two iterator. Since multiple worker are iterating over same page and
> chunk array we need to have a shared iterator, so we grab a spin lock
> and iterate within a lock, so that each worker get and different page
> to process.

I don't quite understand why the bitmap has to be parallel at all. As
far as I understand your approach as described here, the only thing that
needs to be shared are the iteration arrays.  Since they never need to
be resized and such, it seems to make a lot more sense to just add an
API to share those, instead of the whole underlying hash.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel bitmap heap scan
Next
From: Robert Haas
Date:
Subject: Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1