On Wed, Mar 15, 2017 at 10:21 PM, Emre Hasegeli <e...@hasegeli.com> wrote: >> hasegeli=# create table r2 as select (random() * 3)::int as i from >> generate_series(1, 1000000); >> SELECT 1000000 >> hasegeli=# create index on r2 using brin (i); >> CREATE INDEX >> hasegeli=# analyze r2; >> ANALYZE >> hasegeli=# explain select * from only r2 where i = 10; >> QUERY PLAN >> ------------------------------------------------------------------------------------- >> Gather (cost=2867.50..9225.32 rows=1 width=4) >> Workers Planned: 2 >> -> Parallel Bitmap Heap Scan on r2 (cost=1867.50..8225.22 rows=1 >> width=4) >> Recheck Cond: (i = 10) >> -> Bitmap Index Scan on r2_i_idx (cost=0.00..1867.50 rows=371082 >> width=0) >> Index Cond: (i = 10) >> (6 rows) >> >> hasegeli=# select * from only r2 where i = 10;
I am able to reproduce the bug, and attached patch fixes the same. Problem is that I am not handling TBM_EMPTY state properly. I remember that while reviewing the patch Robert mentioned that we might need to handle the TBM_EMPTY and I told that since we are not handling in non-parallel mode so we don't need to handle here as well. But, I was wrong. So the problem is that if state is not TBM_HASH then it's directly assuming TBM_ONE_PAGE which is completely wrong. I have fixed that and also fixed in other similar locations. Please verify the fix. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
fix_tbm_empty.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
