> Your work-around until I fix this is to say
>
> owners.owner_id = pets.owner_id
>
> instead if what you have. In other words, put the
> table on the left side of the join before the equals
> sign instead of after it.
Good idea: Swapping the terms of the JOIN expression does seem to work
D. Richard Hipp wrote:
>
> Likely this has to do with ticket #3015.
> http://www.sqlite.org/cvstrac/tktview?tn=3015
>
Yes, I agree. It seems like the fix may have been too broad.
The problem with the query in that report was the use of an index on the
left table in the join condition.
In the
On Apr 17, 2008, at 12:04 PM, Eric Minbiole wrote:
> I have been using SQLite for about a year now, and have been extremely
> pleased. While testing 3.5.8, I noticed that a SELECT with LEFT OUTER
> JOIN seemed to stop using an index, resorting to a (slow) full table
> scan. A simple (contrived) e
On Apr 17, 2008, at 12:31 PM, Dennis Cote wrote:
> Eric Minbiole wrote:
>>
>> However, I wanted to let others take a look, to see if the
>> issue was with my query (quite possible), or with the new version.
>>
>
> This is definitely an issue with the new version. It is doing a nested
> table scan
Eric Minbiole wrote:
>
> However, I wanted to let others take a look, to see if the
> issue was with my query (quite possible), or with the new version.
>
This is definitely an issue with the new version. It is doing a nested
table scan instead of using the index for the left join.
Dennis Cot
I have been using SQLite for about a year now, and have been extremely
pleased. While testing 3.5.8, I noticed that a SELECT with LEFT OUTER
JOIN seemed to stop using an index, resorting to a (slow) full table
scan. A simple (contrived) example follows:
CREATE TABLE pets (
pet_id INTEGE
6 matches
Mail list logo