Re: [sqlite] Does sqlite has db file-size restriction on Solaris 10?

Hi, Simon, The running server and sqlite database are run in same server; it is not access by network. It is local query and writes. Regards, Liang Kunming. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin

Re: [sqlite] Does sqlite has db file-size restriction on Solaris 10?

On 25 Nov 2013, at 2:08am, Liang Kunming wrote: > Based on my test, create a >3GB files on my Solaris 10 is ok, do you have any > others suggestions? Sorry, no. I am intrigued, however, but the fact that your trace shows IP calls when you didn't mention you were

Re: [sqlite] Does sqlite has db file-size restriction on Solaris 10?

Hi, Simon, Based on my test, create a >3GB files on my Solaris 10 is ok, do you have any others suggestions? bash-3.00# du -hs logs/* 7.0G logs/SilentAlarm.log 25K logs/SilentAlarmError.log 10M logs/systemErr1.txt 4.4M

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On Sun, 24 Nov 2013 16:53:01 +0200 RSmith wrote: > Similarly if one was to add a function which returns a date-dependant > value, such as 'dayOfWeek(x)' and mark it as deterministic for inside > a single query, that would make sense, even though it would be very >

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On Sun, 24 Nov 2013 09:17:20 -0500 Doug Currie wrote: > in computer science we have referential transparency > > http://en.wikipedia.org/wiki/Referential_transparency_ > (computer_science) > > and pure functions > > http://en.wikipedia.org/wiki/Pure_function

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On Nov 24, 2013, at 7:10 PM, Valentin Davydov wrote: > Wait a second... and you'll get different value of datetime('now'). In this > sense datetime() is as deterministic as random(): it may give the same result > next invocation or may not, dependng on various

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On Sat, Nov 23, 2013 at 06:18:29AM -0500, Richard Hipp wrote: > On Sat, Nov 23, 2013 at 5:26 AM, Pepijn Van Eeckhoudt < > pep...@vaneeckhoudt.net> wrote: > > > Is datetime special in thuis context or will constant expression hoisting > > like this happen for any function? > > SQLite must know

Re: [sqlite] Insert with multiple nested selects.

> Perhaps: > > INSERT OR IGNORE INTO table_a > ( > col_a, > col_b, > col_c, > col_d > ) VALUES ( >(SELECT id FROM table_b WHERE name=?) > ,? > ,? > ,(SELECT id FROM table_c WHERE name=?) > ); Hah, I need some time away from this one, not sure what I was

Re: [sqlite] Insert with multiple nested selects.

On Sun, 24 Nov 2013 16:10:58 +, "Joseph L. Casale" wrote: >Hey guys, >Trying to create a statement for use with parameters in a Python execute method >when performing inserts with multiple nested selects. I can adjust it for use >with Python, but I am having issues

Re: [sqlite] Insert with multiple nested selects.

On 24-11-2013 17:10, Joseph L. Casale wrote: Hey guys, Trying to create a statement for use with parameters in a Python execute method when performing inserts with multiple nested selects. I can adjust it for use with Python, but I am having issues when there is more than one nested select.

[sqlite] Insert with multiple nested selects.

Hey guys, Trying to create a statement for use with parameters in a Python execute method when performing inserts with multiple nested selects. I can adjust it for use with Python, but I am having issues when there is more than one nested select. Something such as: INSERT OR IGNORE INTO table_a

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On Sun, Nov 24, 2013 at 4:30 PM, Petite Abeille wrote: > > On Nov 24, 2013, at 3:17 PM, Doug Currie wrote: > > > There is value in compatibility, but those adjectives are awful. > > FWIW, DETERMINISTIC is what Oracle uses: > > >

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

Ugh, my last thought was not well-formed - apologies. When I said: "...can add a function to replace an SQL function to improve it many times for the specific purpose". This would of course hardly matter if the SQL (or SQLite specifically) function was already deterministic (read: cached). My

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

Agreed - also some functions might not be intrinsically deterministic, but it may well be so for the duration of a query. There may need to be some thinking on this. I refer back to a discussion earlier (and subsequent SQLite adaption) which made a date-time reference deterministic within a

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On Nov 24, 2013, at 3:17 PM, Doug Currie wrote: > There is value in compatibility, but those adjectives are awful. FWIW, DETERMINISTIC is what Oracle uses: http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/function.htm#LNPLS1183 I would personally stick to that if

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On Nov 24, 2013, at 6:47 AM, Alek Paunov wrote: > > BTW, I see the term "deterministic" in the SQL99 BNFs: > … > but different in PostgreSQL ("immutable", "stable", etc): There is value in compatibility, but those adjectives are awful. In computer science we have

[sqlite] Fw: Timestamps from different timezones

Hello Christopher, > You absolutely cannot do this automatically unless you know > the source of > each timestamp, any maybe not even then. > Just as a f'rinstance, there are at least 3 different meanings > for EST, and > 2 of them are in the same country: > try -0500, +1000, +1100 for a

Re: [sqlite] Timestamps from different timezones

Hello Keith, Thanks for your reply. > The select returns a timestamp in UTC, not in localtime.  > If you want localtime you need to specify that: > SELECT datetime('2012-05-06T18:57:41-01:00', 'localtime'); Yes, I do want timestamps in UTC only. Otherwise the same SELECT would return a

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

On 23.11.2013 13:18, Richard Hipp wrote: SQLite must know that the function always gives the same output given the same inputs. No every function works that way. Counterexamples include random() and last_insert_rowid(). But most built-in functions are factorable in the same way that