From: | "Jie Zhang" <jzhang(at)greenplum(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | An In-memory Bitmap Index Bug |
Date: | 2005-07-24 01:25:17 |
Message-ID: | BB05A27C22288540A3A3E8F3749B45AB927730@MI8NYCMAIL06.Mi8.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
There is a bug in the in-memory bitmap index on the CVS Tip.
Consider this query: select * from bt1 where g=2 and e=20, which will generate the following query plan:
QUERY PLAN
----------------------------------------------------------------------------------------
Bitmap Heap Scan on bt1 (cost=2041.47..19807.47 rows=8451 width=159)
Recheck Cond: ((e = 20) AND (g = 2))
-> BitmapAnd (cost=2041.47..2041.47 rows=8451 width=0)
-> Bitmap Index Scan on bt1_btree_e (cost=0.00..145.91 rows=25404 width=0)
Index Cond: (e = 20)
-> Bitmap Index Scan on bt1_btree_g (cost=0.00..1895.31 rows=332661 width=0)
Index Cond: (g = 2)
(7 rows)
With default work_mem setting (1024), the bitmap generated for (e=20) will not have lossy pages, while the bitmap generated for (g=2) will have lossy pages.
The problem appears when a page in the first bitmap tries to intersect with the second bitmap. The current code didn't set the page in the first bitmap to lossy after the intersection. As a result, incorrect answers are returned.
A patch is attached in this email.
Sincerely,
Jie Zhang
Greenplum
Attachment | Content-Type | Size |
---|---|---|
pgsql-bitmapscan-bugfix.patch | application/octet-stream | 2.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-24 02:26:14 | Re: An In-memory Bitmap Index Bug |
Previous Message | Andrew Dunstan | 2005-07-23 23:58:21 | Re: [HACKERS] Patch to fix plpython on OS X |