If you were going to do this entirely in memory (perhaps in C, or some similar
language), you would likely use some tree structure where each node keeps track
of the number of descendants (direct and indirect) of that node. That allows
the operations you describe to occur in O(log(N)) time.
It sounds like you've got a way forward on leaks via the malloc() system within
the process space.
Be aware that depending on your system (and the attackers' capabilities), you
might have to worry about other leaks. For instance, if I did a query that
involved a FLOAT index, and then closed
> From: Clemens Ladisch [mailto:clem...@ladisch.de]
> Sent: Friday, October 21, 2016 1:31 AM
> It would be possible to open a 'wrong' file only if someone had created a
> fake database file deliberately.
I think that is generally correct, but "possible ... only if" is perhaps a bit
strong.
A lot of speculation here. I am certainly no SQLite expert.
Your input has 1g positions, taking 187gb, so averaging 187b/position. From
your CREATE TABLE, it looks like to get that size most of your qfrom and qto
are fairly long strings. I'm assuming there are a great many duplications in
If too late for this release, consider it a request for the next release:
Provide a way (pragma, or additional syntax on the command/virtual table) to
have the command-line .import, and the new CSV virtual table, use NUMERIC
column affinity when creating a new table.
I like to think that 10 is
> From: Stephan Buchert [mailto:stephanb007 at gmail.com]
> Sent: Saturday, May 07, 2016 12:10 AM
> Copying the WAL files is probably more efficient than the SQL text solutions
> (considering that roughly 5 GB of binary data are weekly added), and it seems
> easy to implement, so I'll probably
In RAM, the simple implementation would be to have a balanced tree, ordered by
index, where every node knows how many elements are below it, and has pointers
to its children. The tree will have O(logN) depth, following a pointer is O(1),
and, and all of your operations involve a small
For cache eviction, below are you referring to writing dirty pages to disk?
If you are talking about cached reads, the evidence seems to point to many such
pages remaining in some kind of cache.
I perform a recursive grep (Cygwin) on a large directory tree. It takes 4.5m. I
wait five minutes
I may be reading different documentation (or perhaps just misreading it).
https://www.sqlite.org/autoinc.html says (for the no AUTOINCREMENT case, which
applies to the original post) "If no ROWID is specified on the insert ... [the]
usual algorithm is to give the newly created row a ROWID that
I have an engineering application, where double can be part of a key. In cases
where I do a comparison that implies a test for equality, I don't necessarily
care what happens in the really close cases.
SELECT x,y FROM mytable WHERE x >= 1234 AND x < 5678
There may be about a 1 records in
It depends a lot on what kind of duplications you are concerned with. For
instance, a file-system copy would, presumably, have copied any "unique
identifier" that may have been in the file, so it will no longer be unique. To
detect that kind of duplication, I think you really need support at
I'm an SQLite novice, so if I'm wrong about this, I hope someone will correct
me.
The first query will be slower than later queries for the reason Simon
mentioned. However, it may still be possible to get some speed up of the first
query, if it can avoid reading stuff not in the result set and
I have an application file that I'm considering moving to sqlite. Some current
behavior is:
1) Only one writing thread for the lifetime of a logical dataset.
2) The writing thread opens the file with exclusive write access (open fails if
there is another writer, no other writers allowed, but
14 matches
Mail list logo