Re: [sqlite] Setting boundaries in a search

On 2014/07/16 14:55, Rob Willett wrote: I’ll second what Simon says, I use the very same technique for a table with 4M+ records in and its so fast I thought I had an error and looked for bugs in my code. I >assumed (incorrectly) that it would be very slow, It isn’t. In a similar fashion I

Re: [sqlite] Setting boundaries in a search

"Simon Slavin" wrote... On 16 Jul 2014, at 1:23pm, jose isaias cabrera wrote: "Simon Slavin" wrote... CREATE INDEX sci ON startcodes (code,id) You will find that that SELECT will then be blisteringly fast even with millions of rows in your table. I do have

Re: [sqlite] Setting boundaries in a search

"RSmith" wrote... On 2014/07/16 14:23, jose isaias cabrera wrote: "Simon Slavin" wrote... That way is not particularly slow. You just need to have a good index. A good index for that search would be CREATE INDEX sci ON startcodes (code,id) You will find that that SELECT will then be

Re: [sqlite] Setting boundaries in a search

"Rob Willett" wrote... Hi, Can I add my very first piece of advice after listening and reading for the last 6-9 months :) I’ll second what Simon says, I use the very same technique for a table with 4M+ records in and its so fast I thought I had an error and looked for bugs in my code. I

Re: [sqlite] Setting boundaries in a search

All my searches are unique and go across the whole table. The range I select from us normally between 500 and 600 rows. I benchmarked the select over the growth of the database to circa 4m records and the slowdown was negligible. I'm not looking at optimising it as I have far better

Re: [sqlite] Setting boundaries in a search

On 16 Jul 2014, at 1:23pm, jose isaias cabrera wrote: > "Simon Slavin" wrote... > >> CREATE INDEX sci ON startcodes (code,id) >> >> You will find that that SELECT will then be blisteringly fast even with >> millions of rows in your table. > > I do have that INDEX for

Re: [sqlite] Setting boundaries in a search

On 2014/07/16 14:23, jose isaias cabrera wrote: "Simon Slavin" wrote... That way is not particularly slow. You just need to have a good index. A good index for that search would be CREATE INDEX sci ON startcodes (code,id) You will find that that SELECT will then be blisteringly fast even

Re: [sqlite] Setting boundaries in a search

Hi, Can I add my very first piece of advice after listening and reading for the last 6-9 months :) I’ll second what Simon says, I use the very same technique for a table with 4M+ records in and its so fast I thought I had an error and looked for bugs in my code. I assumed (incorrectly) that

Re: [sqlite] Setting boundaries in a search

"Simon Slavin" wrote... On 16 Jul 2014, at 3:21am, jose isaias cabrera wrote: SELECT * from startcodes where code = 'e'; but I want to search only from id >= 8 and <= 14. Is there a way to set the boundary for that SELECT that will only search ids 8-14? I know I

Re: [sqlite] Setting boundaries in a search

"Igor Tandetnik" wrote... On 7/15/2014 10:21 PM, jose isaias cabrera wrote: SELECT * from startcodes where code = 'e'; but I want to search only from id >= 8 and <= 14. Just say so: SELECT * from startcodes where code = 'e' and id between 8 and 14; I know I can do a WHERE id BETWEEN 8

[sqlite] Sqlite FTS4 unicode61 tokenizer with Winrt 8.1

Hi, I am building a winrt app using sqlite, I need to use FTS3/FTS4 with unicode61 tokenize. Throws error when i try to create a table shown below with tokenize unicode61 create virtual table if not exists Address USING fts4 (Address1 TEXT, DATE_CREATED INTEGER,CHANGED_DATE

Re: [sqlite] capturing and testing a hot journal

-Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of mm.w Sent: Tuesday, July 15, 2014 8:34 PM To: R Smith Cc: General Discussion of SQLite Database Subject: Re: [sqlite] capturing and testing a hot journal >> and I stay public

Re: [sqlite] A Potential Bug

In this case, sqlite3VdbeAllocUnpackedRecord is called with pSpace = 0 and szSpace = 0. The calculated value of nOff will also be 0, since pSpace is 0. nByte must be greater than zero, as it is the sum of two positive terms. Therefore the test "if( nByte>szSpace+nOff )" will be true, and the