[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-28 Thread rotaiv
'f'; What indexes should I create? Seems like I only need an index on home.fpath and work.fpath but I wanted to make sure. On Tue, Jul 28, 2015 at 3:13 PM, Simon Slavin wrote: > > On 28 Jul 2015, at 7:55pm, rotaiv wrote: > > > That is the machine. Originally. i

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-28 Thread rotaiv
That is the machine. Originally. it was taking 40+ minutes. I upgraded to the latest version and it decreased to 16 seconds. With indexes, 5 seconds. :-D On Tue, Jul 28, 2015 at 2:53 PM, Simon Slavin wrote: > > On 28 Jul 2015, at 7:43pm, rotaiv wrote: > > > I create indexes

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-28 Thread rotaiv
I create indexes and my original query time dropped from 16 seconds to this: real 0m5.928s user 0m5.361s sys 0m0.565s However, when I use the query you suggested, it was a little slower: real 0m9.827s user 0m8.952s sys 0m0.873s On Mon, Jul 27, 2015 at 5:38 PM, Keith Medcalf wrote: >

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-27 Thread rotaiv
> It's not the older SQLite taking so much longer, it's simply that the file > created with a newer SQLite probably contains a SCHEMA or objects not > readily understood or able to be optimized by the older engine. if the file > was made with the old engine it would perform perfectly well in both t

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-27 Thread rotaiv
> ?WOW! That is an amazing difference. Makes me glad that I'm OCD about > staying relatively current. And please ignore my previous post. I somehow > managed to not register that you would doing a LEFT join, an equi-join.? > I am also OCD about updates. I installed Sqlite using yum right before I

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-27 Thread rotaiv
> Also, I agree with Simon that the query itself, and it's use of NULL, looks > weird. And I don't see where it could find any matches because the "ON > work.fpath = home.fpath" should never match if either fpath is NULL. > > I confess, I understand basic SQL but it is not one of my strengths at al

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-27 Thread rotaiv
text file on my home PC then import that as well. The tables are very simple. Just filename, type, date, time and epoch seconds (easy comparison). On Mon, Jul 27, 2015 at 10:16 AM, Tim Streater wrote: > On 27 Jul 2015 at 13:44, rotaiv wrote: > > > Where is the resource bottleneck t

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-27 Thread rotaiv
Thank for reminding me to check the obvious. The server was using version 3.6.20. I manually upgraded to version 3.8.10.2 and the query completed in 16 seconds. Still not as fast as my home PC but given the age of the hardware, this is understandable. I will take 16 seconds as opposed to 40+ mi

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-27 Thread rotaiv
That is correct - I am looking for records that are empty. I tried this version of the SQL query as well and during my testing, the first example seemed to be more efficient. Also, I have version 3.8.10.2 on my home PC and version 3.6.20 on my server at work. I am going to update the server versi

[sqlite] Query takes 8 seconds on one machine but I abort after 40+ minutes on other machines

2015-07-27 Thread rotaiv
Where is the resource bottleneck that causes a simple query to never complete after 40 minutes I am using sqlite to synchronize files on my home PC and my work PC. I created a file listing of each computer and imported into separate tables. Then I used the following query to locate missing files.