Forums PostgreSQL.fr

fbamiere@yahoo.com

Membre

bloom filters

Bonjour,
j'ai essayé de mettre en oeuvre les bloom filters. j'ai suivi le lien : http://blog.coelho.net/database/2016/12 … index.html

j'ai crée une table foo avec 100 millions de lignes
un index bloom, mais quoi que je fasse, je passe toujours en seq scan.
                                     Table « public.foo »
Colonne |            Type             |                    Modificateurs
---------+-----------------------------+------------------------------------------------------
id      | integer                     | non NULL Par défaut, nextval('foo_id_seq'::regclass)
c1      | integer                     |
c2      | integer                     |
c3      | integer                     |
c4      | integer                     |
c5      | integer                     |
it      | timestamp without time zone | non NULL Par défaut, now()
Index :
    "foo_c1c2c3c4c5" bloom (c1, c2, c3, c4, c5) WITH (length='64', col1='3', col2='3', col3='3', col4='3', col5='3')

idev00=> explain select * from foo where c1=463274 and c2=459458 and c3=291859 and c4=198159;
                                      QUERY PLAN
---------------------------------------------------------------------------------------
Gather  (cost=1000.00..1042428.67 rows=1 width=32)
   Workers Planned: 7
   ->  Parallel Seq Scan on foo  (cost=0.00..1041428.57 rows=1 width=32)
         Filter: ((c1 = 463274) AND (c2 = 459458) AND (c3 = 291859) AND (c4 = 198159))
(4 lignes)

Quelqu'un aurait une idée ?

merci

Marc Cousin

Membre

Re : bloom filters

Il considère que le plan parallèle est moins cher…

marc=# explain (analyze,buffers) select * from foo where c1=463274 and c2=459458 and c3=291859 and c4=198159;
                                                          QUERY PLAN                                                          
------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on foo  (cost=218735.30..218739.32 rows=1 width=32) (actual time=84.289..84.289 rows=0 loops=1)
   Recheck Cond: ((c1 = 463274) AND (c2 = 459458) AND (c3 = 291859) AND (c4 = 198159))
   Buffers: shared hit=7534 read=9649
   ->  Bitmap Index Scan on foo_c1c2c3c4c5  (cost=0.00..218735.29 rows=1 width=0) (actual time=84.284..84.284 rows=0 loops=1)
         Index Cond: ((c1 = 463274) AND (c2 = 459458) AND (c3 = 291859) AND (c4 = 198159))
         Buffers: shared hit=7534 read=9649
 Planning time: 0.785 ms
 Execution time: 84.433 ms
(8 rows)

marc=# set max_parallel_workers_per_gather TO 8;
SET
marc=# explain (analyze,buffers) select * from foo where c1=463274 and c2=459458 and c3=291859 and c4=198159;
                                                       QUERY PLAN                                                       
------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..124529.87 rows=1 width=32) (actual time=1276.689..1276.689 rows=0 loops=1)
   Workers Planned: 4
   Workers Launched: 4
   Buffers: shared hit=8671 read=65071
   ->  Parallel Seq Scan on foo  (cost=0.00..123529.76 rows=1 width=32) (actual time=1249.315..1249.315 rows=0 loops=5)
         Filter: ((c1 = 463274) AND (c2 = 459458) AND (c3 = 291859) AND (c4 = 198159))
         Rows Removed by Filter: 2000000
         Buffers: shared hit=8459 read=65071
 Planning time: 1.047 ms
 Execution time: 1277.830 ms
(10 rows)

Je dirais qu'il est pessimiste sur le coût du bloom… mais bon, c'est une structure statistique, on ne sait pas vraiment ce qui va se passer… et il faut lire tout l'index bloom de toutes façons. Bref, je dirais que le modèle de coût de l'index bloom est assez rudimentaire pour le moment, et qu'il se plante tout simplement sur son coût d'utilisation ici.

---

Marc.