An In-memory Bitmap Index Bug

Поиск
Список
Период
Сортировка
От Jie Zhang
Тема An In-memory Bitmap Index Bug
Дата
Msg-id BB05A27C22288540A3A3E8F3749B45AB927730@MI8NYCMAIL06.Mi8.com
обсуждение исходный текст
Ответы Re: An In-memory Bitmap Index Bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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
generatedfor (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
setthe 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [PATCHES] Patch to fix plpython on OS X
Следующее
От: Tom Lane
Дата:
Сообщение: Re: An In-memory Bitmap Index Bug