On 02/06/2012 05:54 AM, Hamish Allan wrote:
On 5 February 2012 21:20, Roger Binns<rog...@rogerbinns.com> wrote:
SQLite doesn't work on rows - it works on pages. A row will be contained
within one or more pages.
FWIW, I inspected the source for OP_Concat and found that it can
sometimes avoid a memcpy (but presumably not if there isn't enough
space in contiguous free pages).
What are you already doing with regards to size and what are your
constraints? For example the default values will result in a page cache
of 2MB.
I don't have hard constraints. This is for iOS, which monitors user
processes and kills them for what it deems unruly memory usage, where
"unruly" is not publicly defined and is subject to change between OS
versions!
There are numerous existing APIs in SQLite for having fine grained control
over memory allocation.
Thanks for the tips! memory_highwater() agrees with my profiler that
the transient memory requirements are largely flat under standard
concatenation :)
However, FTS4 does appear to take the naive approach of removing and
re-adding everything from its index every time.
Inspecting the source in sqlite3Fts3UpdateMethod(), an UPDATE acts
just like a DELETE in removing the old record. Top-level comments
state that FTS segments are built from the bottom up and are not
updatable.
However, the doclist format seems to be written in such a way that
positions could be copied wholesale from the old record to the new,
prior to appending new positions. Please, can anyone familiar with the
code comment on this?
I think when two doclists are merged both are loaded into memory.
Some types of queries load the entire doclist for a term into
memory too.
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
