Re: Parallel bitmap heap scan

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Parallel bitmap heap scan
Дата
Msg-id 20161017201558.cr34stc6zvxy3mst@alap3.anarazel.de
обсуждение исходный текст
Ответ на Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallel bitmap heap scan
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1