On Wed, Mar 15, 2017 at 8:51 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>> I can try to provide a test case, if that wouldn't be enough to spot
>> the problem.
>
> Thanks for reporting, I am looking into this. Meanwhile, if you can
> provide the reproducible test case then locating the issue will be
> faster.
After trying multiple attempts with different datasets I am unable to
reproduce the issue.
I tried with below test case:
create table t(a int, b varchar);insert into t values(generate_series(1,10000000), repeat('x', 100));insert into t
values(generate_series(1,100000000),repeat('x', 100));
create index idx on t using brin(a);
postgres=# analyze t;
ANALYZE
postgres=# explain analyze select * from t where a>6;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------Gather
(cost=580794.52..3059826.52 rows=110414922 width=105) (actual
time=92.324..91853.716 rows=110425971 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Bitmap Heap Scan
ont (cost=579794.52..3058826.52
rows=46006218 width=105) (actual time=65.651..62023.020 rows=36808657
loops=3) Recheck Cond: (a > 6) Rows Removed by Index Recheck: 4 Heap Blocks: lossy=204401
-> Bitmap Index Scan on idx (cost=0.00..552190.79
rows=110425920 width=0) (actual time=88.215..88.215 rows=19040000
loops=1) Index Cond: (a > 6)Planning time: 1.116 msExecution time: 96176.881 ms
(11 rows)
Is it possible for you to provide a reproducible test case? I also
applied the patch given up thread[1] but still could not reproduce.
[1] https://www.postgresql.org/message-id/attachment/50164/brin-correlation-v3.patch
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
