Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 - Mailing list pgsql-general

From Teodor Sigaev
Subject Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4
Date
Msg-id 48FCA6E6.2090208@sigaev.ru
Whole thread Raw
In response to 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>)
Responses 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>)
List 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 by date:

Previous
From: Luca Ferrari
Date:
Subject: pg_dump is ignoring my pgpass file
Next
From: Glyn Astill
Date:
Subject: Using a variable as tablename ins plpgsql?