> trade_time IN ('2012-07-01', '2012-07-02');
represents two distinct points in a continuum of a DATETIME. Perhaps you
should change to DATE. Even then, it would probably be treated as IN, not
RANGE. Perhaps you really want BETWEEN (a "range") instead of IN (a set).
What version are you usin
On Wed, Jul 11, 2012 at 5:30 PM, Sergei Petrunia wrote:
> I can provide a refutation. Ability to make a combined index access of
>
> 1. Equality with a non-constant: t.sec_id= p.sec_id
> 2. non-equality comparison with constants, trade_time IN ('2012-07-01',
> '2012-07-02')
>
> has been discussed
Thanks for the guidance and references, Shawn.
On Wed, Jul 11, 2012 at 3:37 PM, Shawn Green wrote:
>
> Ranged scans only happen for the last portion of an index being used. OR
> queries (or those using IN) can also only be applied to the last part of an
> index search. This means that if you are
On Tue, Jul 10, 2012 at 05:50:07PM -0400, Jeffrey Grollo wrote:
> Hi,
>
> I’m attempting to optimize a join and am having a difficult time using
> multiple columns from a composite index. The second column of the composite
> key is being used when tested for equality, but not for IN or BETWEEN
> c
On 7/10/2012 5:50 PM, Jeffrey Grollo wrote:
Hi,
I’m attempting to optimize a join and am having a difficult time using
multiple columns from a composite index. The second column of the composite
key is being used when tested for equality, but not for IN or BETWEEN
criteria.
As an example, say t
