Maxim Boguk <[EMAIL PROTECTED]> writes:
> But why? NULL's have some special representation in index which don't work
> same as normal values?
In general, NULLs don't work the same as normal values, no.
The reason this particular query isn't working as you are expecting is
that "foo IS NULL" isn'
Alvaro Herrera wrote:
Maxim Boguk wrote:
Sorry with all my respect to you, you look like wrong.
The difference is that the plan with -1 does not need to sort the
output, because it comes sorted out of the index; so the execution can
be stopped as soon as 5 tuples have come out. With NULL, tha
Maxim Boguk wrote:
> Sorry with all my respect to you, you look like wrong.
The difference is that the plan with -1 does not need to sort the
output, because it comes sorted out of the index; so the execution can
be stopped as soon as 5 tuples have come out. With NULL, that can't be
done.
--
Al
Sorry with all my respect to you, you look like wrong.
Here example:
With NULL's:
mboguk_billing=# EXPLAIN ANALYZE SELECT * from cluster_weight where
cluster_weight.rubric_id IS NULL ORDER BY pos LIMIT 5;
QUERY PLAN
--
Maxim Boguk <[EMAIL PROTECTED]> writes:
> Looks like when indexed search over NULL's added, planner wasn't learned
> right way use such index on "where something is NULL order by ... limit ..."
> queries.
There's nothing wrong with the plan; you've just got too many NULLs to
make it worth using
When i read about 8.3 support indexed queries on NULL values (like rubric_id is
NULL) i was really happy.
But reality strike again... look like NULL in WHERE don't allow effective using
index on (rubric_id, pos) for queries like:
... WHERE rubric_id IS NULL ORDER BY pos LIMIT 5
Here is some de