Subject | Re: Query plan insists on NOT USING an index |
---|---|
Author | Franz J Fortuny |
Post date | 2007-07-04T00:06:12Z |
--- In firebird-support@yahoogroups.com, Dmitry Yemanov <dimitr@...>
wrote:
(where the list is provided):
in (xxx,xxx,xxx,xxx,xxx,xxx)
And the values generated by the subquery are EXACTLY the values that I
placed inside the parenthesis for the IN Predicate to take care of.
So, the problem might not be the IN PREDICATE, but the handling of the
values generated by a subquery to be handled by the IN PREDICATE. This
is where the BUG is located.
BTW: I have tried the ALL OTHER IMAGINABLE FORMS (4 hours of trying)
and I still don't get the darn thing to use the proper index, even if
the JOIN of the tor_equiv table is the first one.
Even if the TOR_EQUIV table is the first one and the others are joined
to it: it will still NOT USE the SUBARTIS index.
This is NOT reliable. Sorry.
FJFortuny
wrote:
>another way.
> This is not a bug, Firebird just cannot handle the IN predicate
>However, it does handle the in predicate PERFECTLY in the first case
(where the list is provided):
in (xxx,xxx,xxx,xxx,xxx,xxx)
And the values generated by the subquery are EXACTLY the values that I
placed inside the parenthesis for the IN Predicate to take care of.
So, the problem might not be the IN PREDICATE, but the handling of the
values generated by a subquery to be handled by the IN PREDICATE. This
is where the BUG is located.
BTW: I have tried the ALL OTHER IMAGINABLE FORMS (4 hours of trying)
and I still don't get the darn thing to use the proper index, even if
the JOIN of the tor_equiv table is the first one.
Even if the TOR_EQUIV table is the first one and the others are joined
to it: it will still NOT USE the SUBARTIS index.
This is NOT reliable. Sorry.
FJFortuny