t; -Original Message-
> From: Jeffrey Grollo [mailto:grol...@gmail.com]
> Sent: Tuesday, July 10, 2012 2:50 PM
> To: mysql@lists.mysql.com
> Subject: Composite Index Usage in Joins
>
> Hi,
>
> I'm attempting to optimize a join and am having a difficult time 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
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 that I’m searching two tables: portfolio and tr
