I tried to use intarray on 8.1 . It seems to give same estimates for anything I ask:
explain analyze select * from objects_hier where tg && array[10001]
explain analyze select * from objects_hier where tg && array[0]
explain analyze select * from objects_hier where tg @ array[10001]
explain analyze select * from objects_hier where tg ~ array[0]
Some of queries cover whole table, some cover none, but all give same estimated number of rows:
Bitmap Heap Scan on objects_hier (cost=2.10..102.75 rows=30 width=337) (actual time=0.028..0.028 rows=0 loops=1)
Recheck Cond: (tg && '{0}'::integer[])
-> Bitmap Index Scan on gistbla2 (cost=0.00..2.10 rows= !! 30 !! width=0) (actual time=0.024..0.024 rows=0 loops=1)
Index Cond: (tg && '{0}'::integer[])
See the number of estimated rows is 30 is all cases.
But actually it varies from whole table (30000 rows) to 0.
Looks like GIST indexes for intarray give no statistic at all.
It makes them much much less useless than they could be.. Because planner can’t plan them well and makes horrible mistakes.
For example, puts nested loops in order when for each of 30k rows it makes an index scan within 5 rows => that leads to 30k nested scans, while it should for each of 5 rows perform single index scan among those 30k.
Yes, I have all necessary indexes on tables.
And yes, I run VACUUM FULL ANALYZE just before the tests.
The lack of estimation is not documented anywhere so I just hope this is a bug and can be fixed fast J
