Re: Possible to force an index UNIQUE SCAN in a join ??

"Spendius" <spendius_at_muchomail.com> wrote:
> > How are you currently analyzing your tables?
> I did a simple ANALYZE TABLE ESTIMATE STATISTICS.
>
> >> Of course an index declared unique exists on table 2.
> > And? Are you under the impression that as long as there
> > is an index on some column, it doesn't really matter which
> > column it is?
> The index is created ON the column that I use in my WHERE
> clauses of course. Sorry I didn't mention this fact...
>
> As I said I can't get an explain plan with a UNIQUE SCAN in
> my join predicate, it always displays a FAST SCAN.

Is the fast scan the inner side of a nested loop join? Or is it part of a hash join or sort join? It is hard to believe the optimizer would choose to do a fast scan for the inner member of a nested loop if there was any way to avoid it.

>I only get
> a UNIQUE SCAN when I explicitly specify a value for this column.

If it is using a hash or sort join, then try giving it a use_nl hint, rather than an index hint.

> Thanks.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB