From: Ilia Kantor <ilia@obnovlenie.ru>
To: pgsql-performance@postgresql.org
Subject: intarray is broken ? (8.1b1)
Date: Mon, 29 Aug 2005 00:41:18 +0400
Message-ID: <auto-000558490720@umail.ru> (raw)
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 :-)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ilia@obnovlenie.ru
Subject: Re: intarray is broken ? (8.1b1)
In-Reply-To: <auto-000558490720@umail.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox