Re: [sqlite] Different temp_store_directory settings okay?

On Mar 4, 2010, at 4:30 PM, Brian Dantes wrote: > D. Richard Hipp wrote: > >> It is OK for different processes to use different >> temp_store_directory > >> settings. The temp_store_directory is only used for TEMP tables. It > >> does not play a roll in the persistent state of the database.

Re: [sqlite] Different temp_store_directory settings okay?

D. Richard Hipp wrote: > It is OK for different processes to use different temp_store_directory > settings. The temp_store_directory is only used for TEMP tables. It > does not play a roll in the persistent state of the database. I was worried because of this statement in the docs: "When

Re: [sqlite] Different temp_store_directory settings okay?

On Mar 4, 2010, at 4:10 PM, Brian Dantes wrote: > Is it okay for two different *processes* using > independent connections to the same database two > have different values for the temp_store_directory > pragma? > > The docs make it clear this is not okay for two > *threads* in the same process

[sqlite] Different temp_store_directory settings okay?

Is it okay for two different *processes* using independent connections to the same database two have different values for the temp_store_directory pragma? The docs make it clear this is not okay for two *threads* in the same process -- but for two processes is not so clear. I am experiencing

[sqlite] wrong output for a select group by to a sub query with a case expression

I'm using sqlite3-3.6.22, downloaded today from sqlite web site. Steps to reproduce: create table test(a real); .import bugdata test select categ, count(1) from (select *, (case when a=0 then 0 else cast((a + 25) / 50 + 0.5 as int) end) as categ from test) a group by categ; 1|10 1|25 3|26

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

It's Objective-C, but all the SQLite interfacing bits are pure C directly driving the SQLite API compiled into the program (3.6.22 amalgamation). On 2010-03-04, at 11:25 AM, Pavel Ivanov wrote: > What language is that? Probably wrapper for this language introduces > its own mutexes. >

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

What language is that? Probably wrapper for this language introduces its own mutexes. Pavel On Thu, Mar 4, 2010 at 2:07 PM, Luke Evans wrote: > Thanks guys. > > Well, I had played with turning off the shared cache, and have just done so > again. > What I'm actually seeing is

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

Thanks guys. Well, I had played with turning off the shared cache, and have just done so again. What I'm actually seeing is serialisation (or at least some apparently quite coarse-grained synchronisation). Here's some logging output on my Mac. The start/finished messages are logged by each

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

On Mar 5, 2010, at 12:50 AM, Luke Evans wrote: > Hi SQLiters, > > We're currently investigating SQLite in an application that needs to > issue a batch of queries (SELECTs) before doing some work with all > the data returned. > > I have been trying to figure out the fastest way to get the >

Re: [sqlite] Fastest concurrent read-only performance (+ threads vs processes)

> The process experiment seems to confirm that very fast independent parallel > queries can be made on the same database, but clearly I would like the same > behaviour using multiple threads (and probably connections) in the same > process.  Is this possible with some specific configuration of

[sqlite] Fastest concurrent read-only performance (+ threads vs processes)

Hi SQLiters, We're currently investigating SQLite in an application that needs to issue a batch of queries (SELECTs) before doing some work with all the data returned. I have been trying to figure out the fastest way to get the results. Given there are no writes involved, I figured there

Re: [sqlite] possible buffer over-read in sqlite3VXPrintf()

>> Shouldn't escarg[] contain a nul-terminated string? > > Yes, I wondered that too when I looked at it again later. In which > case the code ought to be safe. > But if it's true that escarg[] should always be a nul-terminated > string (are you confident of this? I haven't studied the code

[sqlite] AUTO: Bret Patterson/Austin/IBM is out of the office (returning 03/08/2010)

I am out of the office until 03/08/2010. I'm out of the office but checking email once or twice a day and will respond to any high importance issues as quickly as possible. Note: This is an automated response to your message "sqlite-users Digest, Vol 27, Issue 4" sent on 3/4/10 5:00:02.

Re: [sqlite] possible buffer over-read in sqlite3VXPrintf()

Dan Kennedy wrote: > > On Mar 2, 2010, at 6:54 PM, Jonathan Kew wrote: > > > I've run into what appears to be a small bug in this function (from > > sqlite3.c, v 3.6.22). Suggested patch: [snip] > > > > The issue here is that when k reaches zero, the access to escarg[i] > >

Re: [sqlite] Maximum database size?

Hi Roger, Thanks for the explanation. Collin On 3/3/10 11:11 PM, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Collin Capano wrote: > >> Why does it prefer to use >> /var/tmp or some other temp directory as opposed to just using the >> current directory? Is there

Re: [sqlite] game, set, match

On Thu, Mar 04, 2010 at 06:37:02AM +, Simon Slavin scratched on the wall: > > On 4 Mar 2010, at 5:39am, P Kishor wrote: > > > My point was a bit different -- seems like > > only SQLite offers the right mix of functional punch, agile > > performance and lightweight footprint to be a viable

Re: [sqlite] FTS3 bug with MATCH plus OR

Thanks to both Scott and Dan for your answers! Ralf ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Type affinity changed by HAVING clause

I'd say this is definitely a bug. Especially keeping in mind that it's not affinity that changed it's actual datatype of returning value. It's interesting though that affinity for the value remains TEXT and comparison is performed as for text: sqlite> create table t1(a text, b int); sqlite>

Re: [sqlite] Can multiple applications from different hosts access a single database file on NFS at the same time?

> My question is: supposed NFS implementes fcntl()  correctly, can > multiple applications from different hosts access a single database > file on NFS at the same time? If fcntl() is implemented correctly on all hosts using database (including one where the physical disk is located) then yes they

[sqlite] Can multiple applications from different hosts access a single database file on NFS at the same time?

Hi all, My question is: supposed NFS implementes fcntl() correctly, can multiple applications from different hosts access a single database file on NFS at the same time? After reading http://www.sqlite.org/faq.html#q5 and http://www.sqlite.org/lockingv3.html carefully, I still cannot get a

Re: [sqlite] Why is this query faster?

Yes, thanks, that has the same speed as the second query and it looks neater. Has the similar query plan as the second query: order fromdetail --- 0 0 TABLE A3Morb5B4_F USING PRIMARY KEY 0 0 TABLE A3Morb5B4_F WITH

Re: [sqlite] Why is this query faster?

On 4 March 2010 10:54, Bart Smissaert wrote: > One table with this create SQL: > > CREATE TABLE Table1([PATIENT_ID] INTEGER, > [ENTRY_ID] INTEGER PRIMARY KEY, > [READ_CODE] TEXT, > [ADDED_DATE] TEXT, > [START_DATE] TEXT) > > and a non-uique index on PATIENT_ID > > Then

[sqlite] Why is this query faster?

One table with this create SQL: CREATE TABLE Table1([PATIENT_ID] INTEGER, [ENTRY_ID] INTEGER PRIMARY KEY, [READ_CODE] TEXT, [ADDED_DATE] TEXT, [START_DATE] TEXT) and a non-uique index on PATIENT_ID Then the following 2 queries, that give the same result: select * from Table1 t1 where