Re: [sqlite] Multi threaded readers on memory sqlite cannot scale

On 5/15/18, 1:25 AM, "Howard Chu" wrote: Peter Da Silva wrote: > On 5/13/18, 6:48 AM, "sqlite-users on behalf of Howard Chu" wrote: > > SQLightning > > Do you have a link

Re: [sqlite] Multi threaded readers on memory sqlite cannot scale

> On May 14, 2018, at 11:25 PM, Howard Chu wrote: > >> Do you have a link to the currently updated version of this? Google gives me >> projects that haven't been updated since 2015. > > That's the most recent version. So far I haven't seen any compelling new > features in

[sqlite] clocks in SQLite

Dear SQLIters, I use datetime('now') to record when a job gets started and stopped. As soon as a job stops, new is started. Thus stop of the previous should be within a second of the start of the next, as you see in the first few lines. But then the clock jumps. Job 1847 ends at 16:44:11 and

Re: [sqlite] Multi threaded readers on memory sqlite cannot scale

Jens Alfke wrote: On May 14, 2018, at 11:25 PM, Howard Chu wrote: Do you have a link to the currently updated version of this? Google gives me projects that haven't been updated since 2015. That's the most recent version. So far I haven't seen any compelling new

Re: [sqlite] Multi threaded readers on memory sqlite cannot scale

> On May 15, 2018, at 1:04 PM, Howard Chu wrote: > > https://github.com/LMDB/sqlightning/tree/mdb > > > You didn't look carefully enough, so you're in no position to offer advice. It's not supposed to be hide-and-seek! There's a

Re: [sqlite] clocks in SQLite

On May 15, 2018, at 12:49 PM, Roman Fleysher wrote: > > Next job, 2283, is started BEFORE job 1852. No it isn’t. Check the date: > 1852 loginnode4 2018-05-14 18:47:56 > 2283 loginnode4 2018-05-15 18:18:59 It’s starting nearly 24 hours later, the

Re: [sqlite] clocks in SQLite

Tuesday, May 15, 2018, 7:49:32 PM, Roman wrote: > Job 1847 ends at 16:44:11 and job 1852 starts at 18:47:46 (and > actually subsequently dies as evidenced by its stop being NULL). How do you KNOW that your program didn't spend 2 hours 3 minutes either not noticing job 1847 had finished, or

Re: [sqlite] clocks in SQLite

Thank you for pointing the 24 hours. I did not notice the day change. Now, I have no idea how this can happen. I will investigate more. Roman From: Graham Holden [sql...@aldurslair.com] Sent: Tuesday, May 15, 2018 3:39 PM To: Roman Fleysher Cc: General

Re: [sqlite] Weird query plan when sorting by a joined column

There is no LEFT join visible to anyone except someone who is in love with LEFT joins without knowing what one is. Your query is misformed. You proper query ought to be: select * from base b join derived d using (id) order by id; There is no b.id nor d.id in the output row. It is a

Re: [sqlite] unique constraint

On 16 May 2018, at 12:25am, Mark Wagner wrote: > I'm wondering if > someone can explain why this simple test of unique column constraints > doesn't work. At least it doesn't work as I expected it would (i.e. that > the second insert would yield a unique constraint violation). >

Re: [sqlite] unique constraint

I am confused. Too much experimenting :( On Tue, May 15, 2018 at 4:55 PM Simon Slavin wrote: > On 16 May 2018, at 12:25am, Mark Wagner wrote: > > > I'm wondering if > > someone can explain why this simple test of unique column constraints > > doesn't

Re: [sqlite] unique constraint

>OK, at the risk of exposing my lack of edification, I'm wondering if >someone can explain why this simple test of unique column constraints >doesn't work. At least it doesn't work as I expected it would (i.e. >that >the second insert would yield a unique constraint violation). > >create table t

Re: [sqlite] unique constraint

On 2018/05/16 1:25 AM, Mark Wagner wrote: OK, at the risk of exposing my lack of edification... Sometimes you pay the price for taking a risk. :) create table t (k integer primary key, s text UNIQUE); Did you by any chance assume the "UNIQUE" constraint to cover both the fields k and s?

Re: [sqlite] Weird query plan when sorting by a joined column

On 15 May 2018, at 11:12pm, Torsten Landschoff wrote: > when doing a join like > > select * from base b join derived d using (id) order by d.id > > the query plan is abysmal slower than when using > > select * from base b join derived d using (id) order by b.id >

[sqlite] unique constraint

OK, at the risk of exposing my lack of edification, I'm wondering if someone can explain why this simple test of unique column constraints doesn't work. At least it doesn't work as I expected it would (i.e. that the second insert would yield a unique constraint violation). create table t (k

[sqlite] Weird query plan when sorting by a joined column

Hello, I am running into an issue while trying to make our code more efficient when talking to Oracle - what is much faster when going to the fat RDBMS is curiously slow on sqlite. Basically when doing a join like select * from base b join derived d using (id) order by d.id the query plan is

Re: [sqlite] Weird query plan when sorting by a joined column

On 16.05.2018 00:12, Torsten Landschoff wrote: > In case anybody would be so kind and take a look at this I included a > small SQL Script to reproduce. Results here are: > > -- >> $ /opt/sqlite3/bin/sqlite3 -version >> 3.23.2 2018-05-09 02:23:29 >>

Re: [sqlite] unique constraint

Thanks for the responses. Just a brain error. Not sure what I was thinking :) On Tue, May 15, 2018 at 6:55 PM R Smith wrote: > > On 2018/05/16 1:25 AM, Mark Wagner wrote: > > OK, at the risk of exposing my lack of edification... > > Sometimes you pay the price for