Re: Problem in Parallel Bitmap Heap Scan?

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problem in Parallel Bitmap Heap Scan?
Date: 2017-03-21 12:21:50
Message-ID: CAFiTN-suK+Mod_noGy8LpmkSzgvzwhGfNZ0K6vf_gX6rkw2jxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> I noticed a failure in the inet.sql test while running the regression
> tests with parallelism cranked up, and can reproduce it interactively
> as follows. After an spgist index is created and the plan changes to
> the one shown below, the query returns no rows.

Thanks for reporting. Seems like we are getting issues related to
TBM_ONE_PAGE and TBM_EMPTY.

I think in this area we need more testing, reason these are not tested
properly because these are not the natural case for parallel bitmap.
I think in next few days I will test more such cases by forcing the
parallel bitmap.

Here is the patch to fix the issue in hand. I have also run the
regress suit with force_parallel_mode=regress and all the test are
passing.

Results after fix.

postgres=# explain analyze SELECT * FROM inet_tbl WHERE i <>
'192.168.1.0/24'::cidr
ORDER BY i;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
Gather Merge (cost=16.53..16.62 rows=9 width=64) (actual
time=4.467..4.478 rows=16 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Sort (cost=16.52..16.54 rows=9 width=64) (actual
time=0.090..0.093 rows=8 loops=2)
Sort Key: i
Sort Method: quicksort Memory: 25kB
-> Parallel Bitmap Heap Scan on inet_tbl (cost=12.26..16.37
rows=9 width=64) (actual time=0.048..0.050 rows=8 loops=2)
Recheck Cond: (i <> '192.168.1.0/24'::inet)
Heap Blocks: exact=1
-> Bitmap Index Scan on inet_idx3 (cost=0.00..12.25
rows=16 width=0) (actual time=0.016..0.016 rows=16 loops=1)
Index Cond: (i <> '192.168.1.0/24'::inet)
Planning time: 0.149 ms
Execution time: 5.143 ms
(13 rows)

postgres=# SELECT * FROM inet_tbl WHERE i <> '192.168.1.0/24'::cidr
ORDER BY i;
c | i
--------------------+------------------
10.0.0.0/8 | 9.1.2.3/8
10.0.0.0/8 | 10.1.2.3/8
10.0.0.0/32 | 10.1.2.3/8
10.0.0.0/8 | 10.1.2.3/8
10.1.0.0/16 | 10.1.2.3/16
10.1.2.0/24 | 10.1.2.3/24
10.1.2.3/32 | 10.1.2.3
10.0.0.0/8 | 11.1.2.3/8
192.168.1.0/24 | 192.168.1.226/24
192.168.1.0/24 | 192.168.1.255/24
192.168.1.0/24 | 192.168.1.0/25
192.168.1.0/24 | 192.168.1.255/25
192.168.1.0/26 | 192.168.1.226
::ffff:1.2.3.4/128 | ::4.3.2.1/24
10:23::f1/128 | 10:23::f1/64
10:23::8000/113 | 10:23::ffff
(16 rows)

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
fix_parallel_bitmap_handling_onepage.patch application/octet-stream 508 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2017-03-21 12:25:00 Re: ANALYZE command progress checker
Previous Message David Rowley 2017-03-21 12:17:45 Re: BRIN cost estimate