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: Haribabu Kommi <kommi.haribabu@gmail.com>, Rafia Sabih <rafia.sabih@enterprisedb.com>, tushar <tushar.ahuja@enterprisedb.com>, Amit Khandekar <amitdkhan.pg@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-19T17:04:00Z
Lists: pgsql-hackers 
On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> I can imagine it can get executed over and over if plan is something like below.
>
> NestLoopJoin
>     -> SeqScan
>     -> Gather
>         -> Parallel Bitmap Heap Scan
>
> But in such case every time the Inner node of the NLJ will be
> rescanned i.e. Gather will be rescanned which in turn shutdown
> workers.

Yeah, but it looks like ExecReScanGather gets rid of the workers, but
reuses the existing DSM.  I'm not quite sure what happens to the DSA.
It looks like it probably just hangs around from the previous
iteration, which means that any allocations will also hang around.

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