On 2/15/07, Guillaume Smet <[EMAIL PROTECTED]> wrote:
On 2/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think that the
> answer is probably "because the index is lossy for this operator,
> so it has to be checked even if the bitmap didn't become lossy".
> You'd have to check the GIST opclass de
On 2/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I think that the
answer is probably "because the index is lossy for this operator,
so it has to be checked even if the bitmap didn't become lossy".
You'd have to check the GIST opclass definition to be sure.
Any idea on what I have to look for (if
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Guillaume Smet escribió:
>> 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?
> It is in the filter, is it not? Having a recheck would be redundant.
Ye
Guillaume Smet escribió:
> 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=11
Tom,
On 2/13/07, Tom Lane <[EMAIL PROTECTED]> 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 ev
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> So the basic explanation is that it's in both lists due to the partial
> index and only qpqual keeps the condition? I would have expected the
> opposite but it doesn't change anything I suppose?
It gets the right answer, yes. I'm not sure if we could
On 2/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
bitmapqualorig = list_difference_ptr(bitmapqualorig, qpqual);
What's not immediately clear is why the condition was in both lists to
start with. Perhaps idx_lieu_parking is a partial index with this as
its WHERE condition?
Yes, it is: "idx_l
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> What surprises me is that "parking" is in the filter and not in the
> Recheck Cond whereas it's part of the second Bitmap Index Scan of the
> Bitmap And node.
That's probably because of this:
/*
* When dealing with special or lossy operators
Hi all,
I'm currently working on optimizing a couple of queries. While
studying the EXPLAIN ANALYZE output of a query, I found this Bitmap
Heap Scan node:
-> Bitmap Heap Scan on lieu l (cost=12.46..63.98 rows=53 width=94)
(actual time=35.569..97.166 rows=78 loops=1)
Recheck Cond: ('(4190964.8
