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: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-10-17T20:12:17Z
Lists: pgsql-hackers 
On Mon, Oct 17, 2016 at 1:23 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> There is major chance in tidbitmap.c file after efficient hash table
> commit [1] and my patch need to be rebased.
>
> Only parallel-bitmap-heap-scan need to be rebased, all other patch can
> be applied on head as is.
> Rebased version (v2) of parallel-bitmap-heap-scan is attached.

But what's the impact on performance?  Presumably parallel bitmap heap
scan was already slower than the non-parallel version, and that commit
presumably widens the gap.  Seems like something to worry about...

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