Re: Question about Bitmap Heap Scan/BitmapAnd

Tom,

On 2/13/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It gets the right answer, yes. I'm not sure if we could safely put the
> condition into the recheck instead of the filter. The particular code
> I showed you has to go the direction it does, because a condition in the
> filter has to be checked even if the bitmap is not lossy. I seem to
> recall concluding that we had to recheck partial-index conditions even
> if the bitmap is not lossy, but I can't reconstruct my reasoning at the
> moment.

I'm still working on my proximity query, testing PostGIS now. I
noticed an issue with a gist index on a point which seems related to
my previous question.

I have the following in my plan:
-> Bitmap Heap Scan on lieu l (cost=13.37..1555.69 rows=844
width=118) (actual time=3.672..39.497 rows=1509 loops=1)
Filter: (((dfinvalidlieu IS NULL) OR (dfinvalidlieu >= now()))
AND (wgslat IS NOT NULL) AND (wgslon IS NOT NULL) AND (wgslat <>
41.89103400) AND (wgslon <> 12.49244400) AND (earthpoint &&
'0103000020777F0000010000000500000000000040019B334100000020D1D8514100000040019B334100000040ADDE51410000006071B2334100000040ADDE51410000006071B2334100000020D1D8514100000040019B334100000020D1D85141'::geometry)
AND (numlieu <> 49187))
-> Bitmap Index Scan on idx_lieu_earthpoint (cost=0.00..13.37
rows=1249 width=0) (actual time=2.844..2.844 rows=1510 loops=1)
Index Cond: (earthpoint &&
'0103000020777F0000010000000500000000000040019B334100000020D1D8514100000040019B334100000040ADDE51410000006071B2334100000040ADDE51410000006071B2334100000020D1D8514100000040019B334100000020D1D85141'::geometry)

Is it normal I have no recheck cond and the index cond of Bitmap Index
Scan is in the filter? Is it also a consequence of the code you
pointed?

The index was created with:
create index idx_lieu_earthpoint on lieu using gist(earthpoint
gist_geometry_ops);

--
Guillaume