Re: [sqlite] ICU collation

On 20 Dec 2009, at 5:29am, Sylvain Pointeau wrote: > but in german, "*schön*" > can be written "schoen" right? In German German, the rules is that one can do this only when using equipment in which the umlaut does not appear. For instance,

Re: [sqlite] ICU collation

but in german, "*schön*" can be written "schoen" right? On Sat, Dec 19, 2009 at 10:16 PM, Igor Tandetnik wrote: > Sylvain Pointeau wrote: > > please could someone help me to understand ICU inside SQLite? > > > > I have

Re: [sqlite] long time to sort list of random integers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Citek wrote: >> A considerable amount of time in your test script is actually spent in print >> calls to pipes. > > I don't follow. An unordered query takes 3 seconds while an ordered > query takes 99 seconds. Are you saying the sorting

Re: [sqlite] Corrupted database (image is malformed): always the same size

I also using 2.8, but i wondering why your database has 200 kb from the beginning. my databases have only 3 or 4 kb's. But at my host if i am using sqlite queries which are $db-> like, i get the same error. funny thing, but the database is not malformed... > > On 18 Dec 2009, at 3:27pm,

Re: [sqlite] long time to sort list of random integers

On 19 Dec 2009, at 9:10pm, Robert Citek wrote: > However, times take noticeably longer when the dataset size is doubled > to 2 MM records. Querying+index (~160=136+20) took 4x longer than > with the 1 MM dataset, This is not surprising. Twice as much data leading to 4x access time. >

Re: [sqlite] requesting 2 tables about one select

hi, thanks martin for your answer. I tried it, but it put me the names with the the number. array(6) { [0]=> array(4) { [0]=> string(10) "Aion Diary" ["name"]=> string(10) "Aion Diary" [1]=> string(1) "2" ["type"]=> string(1) "2" } ... } The thing is,

Re: [sqlite] long time to sort list of random integers

On Sat, Dec 19, 2009 at 04:10:09PM -0500, Robert Citek scratched on the wall: > Building an index works well for 1 MM records. The build+query time > (~40s=27+10) is about 6x faster than querying without an index > (~240s), but still 6x slower than querying and piping to the sort > command (~6s).

Re: [sqlite] ICU collation

Sylvain Pointeau wrote: > please could someone help me to understand ICU inside SQLite? > > I have some text fields for the German language. > I load the collation with : > SELECT icu_load_collation('de_DE', 'GERMAN'); > > the sort order is good, means it sorts correctly the ä,ö etc > > but it

Re: [sqlite] long time to sort list of random integers

On Sat, Dec 19, 2009 at 10:18 AM, Simon Slavin wrote: > On 19 Dec 2009, at 9:27am, Robert Citek wrote: > >> Does anyone have any pointers on how I can speed up a sqlite3 query >> that sorts a list of random integers? > > What are  you doing that sorts them? An "order by"

[sqlite] ICU collation

Hi, please could someone help me to understand ICU inside SQLite? I have some text fields for the German language. I load the collation with : SELECT icu_load_collation('de_DE', 'GERMAN'); the sort order is good, means it sorts correctly the ä,ö etc but it doesn't try to select: "ä" if I use

Re: [sqlite] long time to sort list of random integers

On Sat, Dec 19, 2009 at 12:46 PM, Roger Binns wrote: > Robert Citek wrote: >> and much longer than >> piping the list of random integers into the sort command. > > A considerable amount of time in your test script is actually spent in print > calls to pipes. I don't

Re: [sqlite] Index is not being used

On Dec 19, 2009, at 3:12 PM, Igor Tandetnik wrote: > > To find all strings beginning with 'a', consider using something > like this: > > SELECT * FROM mytable WHERE mycolumn2 >= 'a' and mycolumn2 < 'b'; Or: SELECT * FROM mytable WHERE mycolumn2 GLOB 'a*'; D. Richard Hipp d...@hwaci.com

Re: [sqlite] Index is not being used

Bert Nelsen wrote: > I have the problem that one index is not taken into account when I execute a > query: > > Second column index: > name: idx_mycolumn2 > collation: - > unique: false > -- > > Results for "SELECT * FROM mytable WHERE mycolumn2 LIKE 'a%'" > 0 > TABLE mytable LIKE is

[sqlite] Index is not being used

Hello! I have the problem that one index is not taken into account when I execute a query: I have 1 table with 2 columns. Each column has an index, but EXPLAIN QUERY PLAN tells me that the second index is not being used. -- First column: name: mycolumn1 type: text collation: nocase unique:

Re: [sqlite] long time to sort list of random integers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Citek wrote: > Does anyone have any pointers on how I can speed up a sqlite3 query > that sorts a list of random integers? Funnily enough I use a sequence of random integers and sort them in my test suite when I need SQLite to spend some time

Re: [sqlite] Sqliteconnection.close() bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zafer Ergül wrote: > There is no problem but in the folder when the connection closed , > created a file which is the same name with database file > but extension is db.db > why It is very difficult to understand to your description and you appear

Re: [sqlite] long time to sort list of random integers

On 19 Dec 2009, at 9:27am, Robert Citek wrote: > Does anyone have any pointers on how I can speed up a sqlite3 query > that sorts a list of random integers? What are you doing that sorts them ? Are they in an indexed column, or are you doing it an ORDER BY clause ? If you have an index,

[sqlite] long time to sort list of random integers

Does anyone have any pointers on how I can speed up a sqlite3 query that sorts a list of random integers? I've noticed that sqlite3 takes a long time to sort random integers, much longer than sorting a series of integers and much longer than piping the list of random integers into the sort

Re: [sqlite] Problem with sqlite3_get_auxdata

Hello! On Saturday 19 December 2009 06:11:04 Igor Tandetnik wrote: > No, it's a table column. "Variable" here means a bound parameter. Basically, > something that doesn't change row to row, and so would benefit from caching. Thanks, I use the first constant value and this work. > Remember,