Re: [HACKERS] Problem in Parallel Bitmap Heap Scan? - Mailing list pgsql-hackers

On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro
<thomas.munro@enterprisedb.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers