Re: BitMapScan performance degradation

=?ISO-8859-1?Q?J=E9r=F4me?= BENOIS <benois@argia-engineering.fr> writes:
>     You can read two results of EXPLAIN ANALYZE command here :
> http://sharengo.org/explain.txt

I think the problem is the misestimation of the size of the reqin3
result:

->  Bitmap Heap Scan on mpng2_ei_attribute reqin3  (cost=28.17..32.18 rows=1 width=4) (actual time=1.512..7.941
rows=1394loops=1) 
      Recheck Cond: (((string_value)::text = '1084520156'::text) AND ((name)::text = 'CategoryID-1084520156'::text))
      ->  BitmapAnd  (cost=28.17..28.17 rows=1 width=0) (actual time=1.275..1.275 rows=0 loops=1)
        ->  Bitmap Index Scan on mpng2_ei_attribute_string_value  (cost=0.00..4.78 rows=510 width=0) (actual
time=0.534..0.534rows=1394 loops=1) 
              Index Cond: ((string_value)::text = '1084520156'::text)
        ->  Bitmap Index Scan on mpng2_ei_attribute_name  (cost=0.00..23.13 rows=2896 width=0) (actual
time=0.590..0.590rows=1394 loops=1) 
              Index Cond: ((name)::text = 'CategoryID-1084520156'::text)

Anytime a rowcount estimate is off by more than a factor of a thousand,
you can expect some poor choices in the rest of the plan :-(.  It looks
to me like the planner is expecting those two index conditions to be
independently selective, when in reality they are completely redundant.
Perhaps rethinking your data model would be a useful activity.

            regards, tom lane