>> Also, I noticed that default plan is
>> "PLAN (stat ORDER PK_STAT INDEX (STAT_USER_ID))".
>> But if I change it to the "PLAN (stat INDEX (STAT_USER_ID))" - query runs
>> immediately..
>
> An obvious example of a bad optimizer choice. With the default plan, the
> engine scans the whole index PK_STAT and trying the appropriate record
> IDs against the bitmap created as a result of the range index
> (STAT_USER_ID) scan. I suspect the two records with USER_ID = 100 have
> quite large ID values (i.e. they're located near the end of the index),
> thus you notice the bad performance.

Hi, thank you for the information.
You are correct, table is quite big (7,330,000 records) and IDs in the query
are near the end: 7,319,123.

Also as per Danny comment - select min(id+0).. works perfectly - optimizer
chooses correct plan.

Is this bad optimizer choice we would expect improved in further versions,
or just have to remember and use workaround or pre-set plan?

> Dmitry

Kirill.