Re: [sqlite] Poor performance with nested query in outer join

2011-12-10 Thread Nick Smallbone
Simon Slavin writes: > On 9 Dec 2011, at 10:25pm, Nick Smallbone wrote: > >> select * from a left natural join (select * from b) where id = 1; > > Try not to use sub-selects when you can use a JOIN instead. > Especially don't use them in combination. If you express this as just > a JOIN you'll

Re: [sqlite] Strange behavior on SQLite 3.7x compared with 3.6.22

2011-12-10 Thread Richard Hipp
On Thu, Dec 8, 2011 at 12:25 PM, Alessandro Merolli wrote: > Hi, > >We've being working with SQLite version 3.6.22 in our project and > we wish to upgrade it to the latest one. During the tests with the new > library version, we noticed a strange behavior related to a trigger which > updat

Re: [sqlite] Very slow query

2011-12-10 Thread Richard Hipp
On Thu, Dec 1, 2011 at 7:42 AM, Peter wrote: > Hi, > > I have a problem with one of my queries which take 2 orders of magnitude > more on Sqlite3 (3.7.9) compared with the identical query on PostgreSQL > (8.4). Times are 2270 ms on Sqlite3 and around 17ms on PG. > Please try using the patch at h

Re: [sqlite] Poor performance with nested query in outer join

2011-12-10 Thread Igor Tandetnik
Black, Michael (IS) wrote: > sqlite> explain query plan select * from a left join b where a.id=1 and > b.id=a.id; Make it select * from a left join b on b.id=a.id where a.id=1; The join condition must be in the ON clause, otherwise the left join behaves like a plain vanilla inner join. -- Ig

Re: [sqlite] Poor performance with nested query in outer join

2011-12-10 Thread Black, Michael (IS)
Natural joins are generally considered to be evil. Too many columns in common can be bad. If you just spell it out it works as expected sqlite> explain query plan select * from a left join b where a.id=1 and b.id=a.id; 0|0|0|SEARCH TABLE a USING COVERING INDEX sqlite_autoindex_a_1 (id=?) (~1

Re: [sqlite] Poor performance with nested query in outer join

2011-12-10 Thread Simon Slavin
On 9 Dec 2011, at 10:25pm, Nick Smallbone wrote: > select * from a left natural join (select * from b) where id = 1; Try not to use sub-selects when you can use a JOIN instead. Especially don't use them in combination. If you express this as just a JOIN you'll find that the optimizer works

[sqlite] Poor performance with nested query in outer join

2011-12-10 Thread Nick Smallbone
Hi list, I have the following schema: CREATE TABLE a(id int primary key); CREATE TABLE b(id int primary key); I want to find information about a particular id, and my query boils down to something like select * from a left natural join (select * from b) where id = 1; (in the real code, t

Re: [sqlite] Command line option equivalent for .read

2011-12-10 Thread David Walker
Thanks Simon that does it It does strike me though that there would be some value in making the in app '.' (dot) commands and the command line options consistent especially as there has been an increase in the number of both as new versions have come about. From a programming perspective I susp

Re: [sqlite] Error: disk I/O error while creating an index

2011-12-10 Thread Richard Hipp
On Fri, Dec 9, 2011 at 4:02 AM, Tal Tabakman wrote: > Hi Guys, > I have an SQLITE database of 1.5 million rows in a single table > each raw looks like: > > 149|25|439198507|-1|0|1|44954|24|17|31|9|9|-1|-1| > > now, from the sqlite command line interface I am creating an on a sincle > intege