From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lossy bitmap scan is broken in GIN |
Date: | 2014-05-10 20:43:06 |
Message-ID: | 536E8F5A.20002@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/10/2014 10:41 PM, Alexander Korotkov wrote:
> Hackers,
>
> GIN hangs on lossy bitmap scan. Here is test case:
>
> create extension btree_gin;
> create table test as (select random() v from generate_series(1,1000000));
> create index test_idx on test using gin(v);
> set work_mem = '16MB';
> select count(*) from test where v > 0.9;
> count
> ───────
> 99916
> (1 row)
>
> Time: 63,142 ms
>
> set work_mem = '64kB';
> select count(*) from test where v > 0.9;
>
> The last query hangs. I've debugged it. It's another bug in this "cursed"
> loop in entryGetItem. Fix is attached.
Hmm, so if we're scanning a bitmap, as in a partial match query, and the
bitmap contains a lossy page reference, and advancePast is set to a
lossy reference to the same page (as it usually will be), we get stuck
in an infinite loop. The first while-loop is responsible for finding the
right block, and doesn't look at the offsets, so it stops on that block.
But the if-test that checks if it's a lossy page doesn't check if
advancePast was also a lossy reference, so it returns it again.
Committed, thanks!
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-05-10 21:00:54 | Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |
Previous Message | Heikki Linnakangas | 2014-05-10 20:42:34 | Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |