Re: [sqlite] Thread safety of serialized mode

On Thu, 16 Feb 2017 21:49 + Tim Streater wrote: > > What's inherently wrong with threads in principle is that there is > > no logic that describes them, and consequently no compiler to > > control that logic. > > [snip remainder of long whinge about threads] > >

Re: [sqlite] Thread safety of serialized mode

On Thu, 16 Feb 2017 16:21:06 -0700 Warren Young wrote: > https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > Threads aren?t just distasteful from an implementation standpoint, > they?re *mathematically unsound*. Thank you for that. I think I encounted

Re: [sqlite] Why is this so much more efficient?

You can actually index functions or expression: https://www.sqlite.org/expridx.html On Thu, Feb 16, 2017 at 9:32 PM, Cecil Westerhof wrote: > 2017-02-16 21:10 GMT+01:00 Dominique Pellé : > > > Cecil Westerhof wrote: > >

Re: [sqlite] bug: fields from external (being updated) table cannot be used in "order by" clause of a subselect

On Wed, 15 Feb 2017 12:06:58 +0100 Marek Wieckowski wrote: > The thing is that in principle there is nothing wrong with using > test.xxx fields in the subselect: there really should be no > difference whether you use them in "where" or "order by"... The fact > that sqlite does

Re: [sqlite] Thread safety of serialized mode

> On Feb 16, 2017, at 11:49 AM, Warren Young wrote: > > A software developer who refuses to learn about his processor’s assembly > language is like trying to become an electrical engineer without learning > anything about physics. In this case what you need to read is

Re: [sqlite] Thread safety of serialized mode

Taking it off-list, since there is zero remaining connection to SQLite now: > On Feb 16, 2017, at 2:49 PM, Tim Streater wrote: > > On 16 Feb 2017 at 18:30, James K. Lowden wrote: > >> On Tue, 14 Feb 2017 17:05:30 -0800 >> Darren Duncan

Re: [sqlite] Thread safety of serialized mode

On Thu, 16 Feb 2017, Warren Young wrote: Taking it off-list, since there is zero remaining connection to SQLite now: Thank you for taking it off list. How can we expect people to write threaded programs when even a simple integer increment is prone to race conditions and read-modify-write

Re: [sqlite] Deprecated OSX functioon

> On Feb 16, 2017, at 1:02 PM, James Walker wrote: > > For what it's worth, the OS header recommends replacing it with the function > atomic_compare_exchange_strong, which I assume refers to the C++11 template > function. It’s also available in C as a macro defined

Re: [sqlite] Thread safety of serialized mode

On 16 Feb 2017 at 18:30, James K. Lowden wrote: > On Tue, 14 Feb 2017 17:05:30 -0800 > Darren Duncan wrote: > >> There is nothing inherently wrong with threads in principle > > What's inherently wrong with threads in principle is that there is

Re: [sqlite] Thread safety of serialized mode

> On Feb 16, 2017, at 6:26 PM, James K. Lowden wrote: > > It doesn't change the fact that the OS has subverted the > guarantees your language would otherwise provide, such as the atomicity > of ++i noted elsewhere in this thread. It’s not the OS, it’s the

Re: [sqlite] Thread safety of serialized mode

If you look at the original underlying NT I/O architecture that Cutler implemented - it is a thing of beauty that's based in async patterns, and not threads. It was the Win32 wrappers over the NT subsystem that tried to make things "easier" for developers to deal with, which forced synchronous

Re: [sqlite] Why is this so much more efficient?

Aliases in SQL are not the same as variables in most procedural languages. So every time you mention 'totaltime' SQLite is probably recalculating that value by adding all the columns together. See the various discussions regarding no deterministic (random) functions last year. Less references

[sqlite] About the performance of recursive WITH

Hi, This post concerns a strange (imho) behaviour of recursive WITH update query as far as execution time is concerned. I have created (in an "In memory" DB) a table that stores a set of nodes arranged in a tree structure (actually the skeleton of the contents of a Windows folder):

Re: [sqlite] sqlite3 hangs on query

On 15/02/2017 23:36, Richard Hipp wrote: On 2/15/17, Richard Hipp wrote: It is an optimization opportunity, not a bug. That optimization is now on trunk. Very cool! Thanks, - Heiner ___ sqlite-users mailing list

Re: [sqlite] FTS3 tokenize unicode61 does not remove diacritics correctly?

Hello, On 2017-02-16 10:53, artur.krol.elea...@sqlite.org wrote: [...] The result is: eoałzzcneoałzzcnlł It seems diacritics from letter „ł” and „Ł” was not removed. Is it a sqlite bug? In general, overlays (slash, crossbars, etc.) are considered as diacritics, however, Unicode does not

Re: [sqlite] Multiple connections, page sizes and cache

I've now built an inventory of all our connections and their lifetimes. They come in three primary classes: 1) Perpetual -- opened on app startup, closed on shutdown 2) Periodical, transient, serial -- only one at a time, happens quite rarely (online backup) 3) Stochastic, transient, concurrent

Re: [sqlite] About the performance of recursive WITH

H. With the current head of trunk ... I run this and the recursive version takes 93 milliseconds vs the iterative version which takes 203 milliseconds. Creating all possible covering indexes takes 110 milliseconds vs 141 milliseconds. Creating only used/required covering indexes takes 93

[sqlite] FTS3 tokenize unicode61 does not remove diacritics correctly?

Hi all, I have an issue with FTS3 (http://www.sqlite.org/fts3.html). I am creating virtual table using fts3 to query tokens: CREATE VIRTUAL TABLE tok1 USING fts3tokenize(unicode61); Documentation says: „By default, "unicode61" also removes all diacritics from Latin script characters.”; When I

Re: [sqlite] Group contiguous rows (islands)

@ Pasma and Hainaut, Thanks again, that looks promising ! Jonathan Message: 42 Date: Wed, 15 Feb 2017 21:10:10 +0100 From: "E.Pasma" To: SQLite mailing list Subject: Re: [sqlite] Group contiguous rows (islands) Message-ID:

[sqlite] Deprecated OSX functioon

This has been coming across my console when building Sqlite since upgrading to Mac OSX Sierra a few months ago. FWIW. Building sqlite3 shell... sqlite3.c:20839:17: warning: 'OSAtomicCompareAndSwapPtrBarrier' is deprecated: first deprecated in macOS 10.12 - Use atomic_compare_exchange_strong()

Re: [sqlite] Why is this so much more efficient?

Basically, the DB size and compactness state influences the speed at which values are read. (Every update implies a read). Add to that the fact that these functions verge on the bottom edge of time consumers... It's like testing diffusion speed of a perfume in a hurricane. Glad you found

[sqlite] 'misuse at line...' sqlite3_config

I have this bit of code I've had around forever, I recently enabled SQLITE_CONFIG_LOG and have been getting a misuse because I'm calling sqlite3_config after initialization. The one I'm calling is SQLITE_CONFIG_GETMALLOC which should read the internal routines already in use; I then override some

Re: [sqlite] Difference between min and max time, especially for sys

> On Feb 15, 2017, at 11:47 AM, Cecil Westerhof wrote: > > But the difference between sys can be almost a factor twenty. What seems very > big to me. Yup. There is a huge speed difference between the kernel going to the disk/SSD to read from a file, vs. the kernel

Re: [sqlite] Thread safety of serialized mode

On Tue, 14 Feb 2017 17:05:30 -0800 Darren Duncan wrote: > There is nothing inherently wrong with threads in principle What's inherently wrong with threads in principle is that there is no logic that describes them, and consequently no compiler to control that logic.

Re: [sqlite] Thread safety of serialized mode

On Wed, 15 Feb 2017 09:40:13 -0800 Jens Alfke wrote: > https://en.wikipedia.org/wiki/Communicating_sequential_processes > Also search YouTube for Rob Pike's presentations on CSP in Go. It will help clarify

Re: [sqlite] Thread safety of serialized mode

On Wed, 15 Feb 2017 12:34:51 + Simon Slavin wrote: > Two disadvantages are that threads are indistinguishable to anything > but the owner and don?t know how to keep out of each-other?s way. By > the time you?ve devised some sort of mutex/locking/blocking mechanism >

Re: [sqlite] 3.17.0 does not read updated DB

> On Feb 15, 2017, at 9:51 PM, Roman Fleysher > wrote: > > My mistake: I do not update DB. I rename (unix mv) the DB. I wouldn’t recommend doing that to an open database! (a) I don’t think it’s formally specified when SQLite opens or closes the database file.

Re: [sqlite] Thread safety of serialized mode

On Wed, 15 Feb 2017 07:55:16 -0700 "Keith Medcalf" wrote: > Note that for several modern OSes, the OS is nothing more than a > discontiguous saved segment (DCSS) which is mapped into *every* > process space and that process isolation is more of a myth than a > reality. Are

Re: [sqlite] Why is this so much more efficient?

2017-02-16 21:10 GMT+01:00 Dominique Pellé : > Cecil Westerhof wrote: > > > I have a table vmstat that I use to store vmstat info. ;-) > > At the moment it has more as 661 thousand records. > > > > In principle the values of usertime,

[sqlite] SQLite Options

I started writing SQLite code about two years ago (Visual Studio 2013, C#, WPF) ... with a significant delay, since then, because of a physical move. The code is written for a specific use on my computer ... no other users. SQLite was chosen so my sons could eventually install this program on

Re: [sqlite] Thread safety of serialized mode

On Feb 15, 2017, at 4:40 AM, Darren Duncan wrote: > > On 2017-02-15 2:40 AM, Clemens Ladisch wrote: >> Cecil Westerhof wrote: >> >> And just like with assembly code, you also have to count the time spent >> writing it, and debugging the result. > > Also, its a long

Re: [sqlite] Smallest reasonable cache size

Kim Gräsman wrote: > Hi all, > > In my battles with lots of connections competing over precious cache > memory, I've considered giving some non-critical connections zero > cache using `PRAGMA cache_size=0`. > > Is this a reasonable thing to do? If zero is too extreme, what

Re: [sqlite] Difference between min and max time, especially for sys

2017-02-16 19:31 GMT+01:00 Jens Alfke : > > > On Feb 15, 2017, at 11:47 AM, Cecil Westerhof > wrote: > > > > But the difference between sys can be almost a factor twenty. What seems > very big to me. > > Yup. There is a huge speed difference between

Re: [sqlite] Thread safety of serialized mode

On Feb 15, 2017, at 5:03 AM, a...@zator.com wrote: > > I suppose someday, programming languages can do an analogous translation in > our limited but safe, sequential programs. Not as long as we require side effects to achieve anything of practical value. Any form of I/O is a “side effect” by

Re: [sqlite] Why is this so much more efficient?

Cecil Westerhof wrote: > I have a table vmstat that I use to store vmstat info. ;-) > At the moment it has more as 661 thousand records. > > In principle the values of usertime, systemtime, idletime, waittime and > stolentime should add up to 100. I just wanted to check

[sqlite] Smallest reasonable cache size

Hi all, In my battles with lots of connections competing over precious cache memory, I've considered giving some non-critical connections zero cache using `PRAGMA cache_size=0`. Is this a reasonable thing to do? If zero is too extreme, what might a more moderate small cache size be? 32? 64? 100?

Re: [sqlite] Smallest reasonable cache size

On 2/16/17, Kim Gräsman wrote: > I've considered giving some non-critical connections zero > cache using `PRAGMA cache_size=0`. > > Is this a reasonable thing to do? Yes. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users

Re: [sqlite] Thread safety of serialized mode

www.microsoft.com ... The only time the OS is not "mapped" into the process address space is if you are running 32-bit code on a 64-bit OS. In that case it has to use an imitation syscall trampoline stored at the top of the 4GB 32-bit address space to jump into 64-bit mode to access the OS

Re: [sqlite] Deprecated OSX functioon

On 2/16/2017 7:40 AM, Ward WIllats wrote: This has been coming across my console when building Sqlite since upgrading to Mac OSX Sierra a few months ago. FWIW. Building sqlite3 shell... sqlite3.c:20839:17: warning: 'OSAtomicCompareAndSwapPtrBarrier' is deprecated: first deprecated in macOS

Re: [sqlite] SQLite Options

On 16 Feb 2017, at 8:40pm, Clyde Eisenbeis wrote: > Is there an SQLite version that is comprised of fewer dlls, etc.? ... > Perhaps SQLite3? If you’re writing C or C++ code all you need is the amalgamation source code files from the SQLite3 site. You compile them into your

Re: [sqlite] Thread safety of serialized mode

It seems like the discussion has turned into a general programming discussion unrelated to SQLite3. Does anyone have an idea about this specific problem that we encountered (see quoted message below)? It is not clear to me if this is a threading issue, or memory corruption issue, or if it is