Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4
От | Teodor Sigaev |
---|---|
Тема | Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 |
Дата | |
Msg-id | 48FCA6E6.2090208@sigaev.ru обсуждение исходный текст |
Ответ на | Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4
|
Список | pgsql-general |
> Hmm. So the problem seems to be statable as "a full-index scan on a > GIST index might fail to return all the rows, if the index has been > modified since creation". Teodor, can you think of anything you > changed recently in that area? I still can't reproduce the bug, but found useless recheck condition with bitmap check: drop table if exists qq; select 1 as st , 1::int4 as t into qq from generate_series(1,10000) as t; create index qqidx on qq using gist (st) where t =1; INSERT INTO qq (SELECT (4 * random())::int4, (4 * random())::int4 from generate_series(1,10000)); # explain select t, count(1) from qq where t =1 group by t; QUERY PLAN ----------------------------------------------------------------------------- GroupAggregate (cost=19.62..633.49 rows=1 width=2) -> Bitmap Heap Scan on qq (cost=19.62..630.28 rows=640 width=2) Recheck Cond: (t = 1) -> Bitmap Index Scan on qqidx (cost=0.00..19.46 rows=640 width=0) -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-general по дате отправления: