Re: AW: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread John Stanton
:[EMAIL PROTECTED] Gesendet: Dienstag, 3. Juli 2007 12:12 An: sqlite-users@sqlite.org; [EMAIL PROTECTED] Betreff: Re: [sqlite] Re: In Mem Query Performance Hi Ken, Thanks a lot. But this would require the key to be short. Will Check if this is acceptable to all as we may not be able to port old db

AW: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread Michael Ruck
. Juli 2007 18:21 An: sqlite-users@sqlite.org; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Betreff: Re: [sqlite] Re: In Mem Query Performance Hi, As said, i used a seperate ID (hash) but it made the performance very bad. Now it takes minutes.[Version: 3.4.0] regards ragha unsigned long idGen(const

Re: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread RaghavendraK 70574
/Now Query Data. time_t start = time(0); for(int k=0;k<10 ;k++) { //idKey = idGen(data[k]); ret = sqlite3_bind_int64(pVM, sqlite3_bind_parameter_index(pVM, ":xyz"), idKeyArr[k]);

AW: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread Sylko Zschiedrich
rg; [EMAIL PROTECTED] Betreff: Re: [sqlite] Re: In Mem Query Performance Just a thought regarding this key issue. enhancement for sqlite, enable a "reverse Key" indexing method. Would this be a simple change? Ken "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>

Re: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread Ken
Just a thought regarding this key issue. enhancement for sqlite, enable a "reverse Key" indexing method. Would this be a simple change? Ken "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: Hi >Hi Ken, > >Thanks a lot. >But this would require the key to be short. Will Check if this is

Re: AW: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread Ken
delete it! * - Original Message - From: Ken Date: Tuesday, July 3, 2007 0:46 am Subject: Re: [sqlite] Re: In Mem Query Performance > Timings: > > Calling Test Now > TIME_ms=1210 > start=1183394494 > end=1183394496 > > Calling Test Now > TIME_ms=1164 > start=1183394504 >

AW: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread Michael Ruck
Nachricht- Von: RaghavendraK 70574 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 3. Juli 2007 12:12 An: sqlite-users@sqlite.org; [EMAIL PROTECTED] Betreff: Re: [sqlite] Re: In Mem Query Performance Hi Ken, Thanks a lot. But this would require the key to be short. Will Check if this is acceptable

Re: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread [EMAIL PROTECTED]
Hi >Hi Ken, > >Thanks a lot. >But this would require the key to be short. Will Check if this is acceptable >to all as we may not be able to port old db data if the key format is changed. > Perhaps the key can be modified only for comparation. You store the key as you want, but before compare

Re: [sqlite] Re: In Mem Query Performance

2007-07-03 Thread RaghavendraK 70574
<[EMAIL PROTECTED]> Date: Tuesday, July 3, 2007 0:46 am Subject: Re: [sqlite] Re: In Mem Query Performance > Timings: > > Calling Test Now > TIME_ms=1210 > start=1183394494 > end=1183394496 > > Calling Test Now > TIME_ms=1164 > start=1183394504 > end=118

Re: [sqlite] Re: In Mem Query Performance

2007-07-02 Thread Ken
Timings: Calling Test Now TIME_ms=1210 start=1183394494 end=1183394496 Calling Test Now TIME_ms=1164 start=1183394504 end=1183394505 (time in Ms is 1.2 and 1.1 ... ) Data generated using: #include #include #include #include using namespace std; int main() {

Re: [sqlite] Re: In Mem Query Performance

2007-07-02 Thread Eduardo Morras
At 12:16 02/07/2007, you wrote: Hi, Pls notify me if it can be brought down to 1 sec. There is no mem constraint. I don't know x86 asm or gcc for x86, but in powerpc asm, if i use altivec libraries (libfreevec, f.e.) for string comparations, mem moves/copies, sorts etc... i get from x2 to

Re: [sqlite] Re: In Mem Query Performance

2007-07-02 Thread RaghavendraK 70574
> the intended recipient(s) is prohibited. If you receive this e- > mail in error, please notify the sender by phone or email > immediately and delete it! > > ************************* > - Original Message - > From: Joe Wilson <[EMAIL PROTECTED]> > Date: Sunday, July 1, 2007 12:47 pm > Subject: Re: [

Re: [sqlite] Re: In Mem Query Performance

2007-07-01 Thread RaghavendraK 70574
ect: Re: [sqlite] Re: In Mem Query Performance > In addition, > > - make a new index only on column1 > - move the prepare before the loop to avoid reparsing the SELECT > each time > - use sqlite3_bind_* and sqlite3_reset in the loop. > - move finalize after the lo

Re: [sqlite] Re: In Mem Query Performance

2007-07-01 Thread John Stanton
than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! * - Original Message - From: "A. Pagaltzis&

Re: [sqlite] Re: In Mem Query Performance

2007-06-30 Thread Joe Wilson
In addition, - make a new index only on column1 - move the prepare before the loop to avoid reparsing the SELECT each time - use sqlite3_bind_* and sqlite3_reset in the loop. - move finalize after the loop. - query the test table directly - not the temporary ttest table. - don't SELECT * if you

Re: [sqlite] Re: In Mem Query Performance

2007-06-30 Thread Joe Wilson
Your keys are too large and have the same leading characters. Since the first hundred characters are the same you waste a lot of CPU time in comparisons. Try to get your total key size down to a fraction of that size. At least change your program to generate keys of this form instead and it

Re: [sqlite] Re: In Mem Query Performance

2007-06-30 Thread RaghavendraK 70574
f the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or emai

[sqlite] Re: In Mem Query Performance

2007-06-30 Thread A. Pagaltzis
Hi RaghavendraK, * RaghavendraK 70574 <[EMAIL PROTECTED]> [2007-06-25 08:45]: > When the DB is opened in "in Memory mode",performance of query > does not improve. For table which has 10 columns of type Text > and each column having 128bytes data and having a total of > 1 records. that is