On Wed, Mar 15, 2017 at 8:51 PM, Dilip Kumar <[email protected]> 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 on t (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 ms
Execution 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
