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
"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
"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
"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
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
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
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
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
"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
"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
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
-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
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
13 matches
Mail list logo