Thank you both for the discussion and conclusion.
2015-05-24 18:32 GMT+02:00 Simon Slavin :
>
> On 24 May 2015, at 4:58pm, Keith Medcalf wrote:
>
> > This is not possible and would make an update operation incredibly
> slow. What you mean is that a row which is not updated is not updated. A
>
ShadowMarta at yahoo.de wrote:
> Do you have some explanation of the terrible performace of "NOT EXIST" &
> "LEFT JOIN" versus "NOT IN" as well ?
FTS tables can do two types of queries efficiently:
- lookups by rowid/docid;
- searches with MATCH.
Anything else (such as your "WHERE id = ?") ends
Thank You Clemens,
>>INSERT INTO OCR(docid, FullOCR) VALUES (42, 'xxx');
I understand now what you are trying to tell me I have misunderstood the
documentation. - or lack of it -
Do you have some explanation of the terrible performace of "NOT EXIST" &
"LEFT JOIN" versus "NOT IN" as well ?
On 24 May 2015, at 4:58pm, Keith Medcalf wrote:
> This is not possible and would make an update operation incredibly slow.
> What you mean is that a row which is not updated is not updated. A row which
> is updated, even if you are re-writing the same value, *IS* an update
> operation.
Hi all,
When I do an update in a huge table, should it write it like this
UPDATE T1 SET F1=replace(F1, 'x', 'y') WHERE F1 LIKE '%x%';
or without where clause like this
UPDATE T1 SET F1=replace(F1, 'x', 'y');
T1 has an index on F1, which is a TEXT field.
thanks
gert
On 24 May 2015, at 4:16pm, Gert Van Assche wrote:
> When I do an update in a huge table, should it write it like this
>UPDATE T1 SET F1=replace(F1, 'x', 'y') WHERE F1 LIKE '%x%';
> or without where clause like this
>UPDATE T1 SET F1=replace(F1, 'x', 'y');
>
> T1 has an index on
ShadowMarta at yahoo.de wrote:
>> You should drop the ID column, and in your queries use the docid instead.
>
> Not possible.
> I fill the rows in a parallel loop, the IDs are in disorder and they are the
> link to table ?ART.ID?.
INSERT INTO OCR(docid, FullOCR) VALUES (42, 'xxx');
Regards,
Hello,
The following code
-- beg --
CREATE TEMP TABLE t (pk INTEGER PRIMARY KEY, i);
CREATE TEMP TABLE b (before_pk, i);
CREATE TEMP TABLE a (after_pk, i);
CREATE TEMP TRIGGER tb BEFORE INSERT ON t FOR EACH ROW
BEGIN
INSERT INTO b VALUES (NEW.pk, NEW.i);
END;
CREATE TEMP TRIGGER ta AFTER
On 24-5-2015 09:20, Marco Bambini wrote:
> Luuk, that's really really funny thanks.
>
> Starting from sqlite 3.8.10 sqlitediff.exe has been added to the official
> sqlite distribution.
> I downloaded both the Amalgamation version and the Alternative Source Code
> Formats from the official
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2015 02:39 AM, Philip Bennefall wrote:
> I have looked at the example VFS implementations, but it is hard
> to determine which parts of the code that are implementation
> details as opposed to being part of the stable public API so to
>
Hi all,
I have been interested in the VFS layer of SqLite for a while, and found
the following article to be very useful:
http://www.sqlite.org/vfs.html
However, it ends right when it is about to go into the actual details of
how to implement a VFS. It would be great if that essay could be
I searched stack overflow for "sqlite3_vfs_register" and got a few hits. For
example, this was a good starting point on which I based my own VFS.
http://stackoverflow.com/a/3842409/236415
Jeff
> On May 24, 2015, at 4:39 AM, Philip Bennefall wrote:
>
> Hi all,
>
> I have been
Hi Clemens,
I really appreciate your input but non of your origination have anything to
do with the problem at hand.
I just want to make sure this thread not get deflected.
The problem is ?performance?.
34157ms, 47924ms vs. 103ms
>>SQLite ignores pretty much anything except the column names
> But SQLite knows not to UPDATE a row when your update changes no values.
This is not possible and would make an update operation incredibly slow. What
you mean is that a row which is not updated is not updated. A row which is
updated, even if you are re-writing the same value, *IS* an
The index on the F1 column is irrelevant -- it might not be used unless it is
significantly faster to scan than the table itself. On the other hand it will
have to be updated for each row in T1 that is updated where the value of F1 is
re-written (not necessarily changed).
The WHERE clause
Luuk, that's really really funny thanks.
Starting from sqlite 3.8.10 sqlitediff.exe has been added to the official
sqlite distribution.
I downloaded both the Amalgamation version and the Alternative Source Code
Formats from the official download page but I wasn't able to find the diff
code,
On 24-5-2015 08:39, Marco Bambini wrote:
> Where can I download sqlitediff and its source code?
>
http://lmgtfy.com/?q=sqlitediff=1
or, more correct:
http://lmgtfy.com/?q=sqlitediff+source
On 23-5-2015 21:14, Darren Duncan wrote:
> More like It'll be out in time for Christmas, where the specific year
> isn't mentioned. -- Darren Duncan
>
> On 2015-05-23 11:09 AM, Mikael wrote:
>> This sounds like it means we'll have it 2.5-5 years then.. so 2018 maybe,
>>
ah, that's in the year
Where can I download sqlitediff and its source code?
Thanks.
--
Marco Bambini
http://www.sqlabs.com
http://twitter.com/sqlabs
http://instagram.com/sqlabs
On 5/24/15, Marco Bambini wrote:
> I wasn't able to find the diff
> code,
https://www.sqlite.org/src/artifact/0748c0daed08f31e
--
D. Richard Hipp
drh at sqlite.org
This sounds like it means we'll have it 2.5-5 years then.. so 2018 maybe,
Sounds about correct? :)
2015-05-23 23:06 GMT+05:30 Stephen Chrzanowski :
> SQLite4 is a dev "toy". It isn't going to be released any time soon.
>
> On Sat, May 23, 2015 at 6:09 AM, Mikael wrote:
>
> > SQLite4 looks
21 matches
Mail list logo
