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