Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org>
Subject: Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4
Date: 2008-10-20 17:16:09
Message-ID: 5428.1224522969@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> I still can't reproduce the bug, but found useless recheck condition with bitmap
> check:

> 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)

No, it's not useless. If the bitmap goes lossy, we have to recheck the
index predicate too, because we'll be looking at all rows on the
indicated page(s) and there's no guarantee that they all match the
predicate.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthias Karlsson 2008-10-20 18:20:49 Re: Slow delete with with cascading foreign keys
Previous Message Martin Gainty 2008-10-20 17:08:46 Re: Booth Volunteers for LISA 08 (San Diego)