Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NOT operator lose index #24

Closed
klpx opened this issue Sep 30, 2016 · 1 comment
Closed

NOT operator lose index #24

klpx opened this issue Sep 30, 2016 · 1 comment

Comments

@klpx
Copy link

klpx commented Sep 30, 2016

Hi! Is it bug? Or what i do wrong?

=> explain analyze select * from mytable where ( data @@ 'NOT attr = *');
                                                      QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
 Seq Scan on mytable  (cost=0.00..101937.27 rows=506315 width=254) (actual time=0.080..920.274 rows=483749 loops=1)
   Filter: (data @@ '(NOT "attr" = *)'::jsquery)
   Rows Removed by Filter: 23073
 Planning time: 2.892 ms
 Execution time: 966.762 ms

=> explain analyze select * from mytable where ( data @@ 'attr = *');
                                                                QUERY PLAN                                                              
----------------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on mytable  (cost=31.93..1951.83 rows=507 width=254) (actual time=41.431..135.250 rows=23073 loops=1)
   Recheck Cond: (data @@ '"attr" = *'::jsquery)
   Heap Blocks: exact=13967
   ->  Bitmap Index Scan on mytable_data_idx1  (cost=0.00..31.80 rows=507 width=0) (actual time=38.447..38.447 rows=23073 loops=
         Index Cond: (data @@ '"attr" = *'::jsquery)
 Planning time: 2.073 ms
 Execution time: 138.120 ms
(7 rows)

@akorotkov
Copy link
Contributor

In jsquery indexes have lossy representation of keys: hashes are stored instead of strings. That causes false positives which are eliminated during recheck. But in case of NOT, false positives may turn into false negatives which can't be handled. This is why NOT clauses are not optimized using index altogether.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants