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 |
- [PERFORM] intarray is broken ? (8.1b1) Ilia Kantor