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? Many thanks, Hamish _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
