-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/02/12 12:09, Hamish Allan wrote: > Sure, but a row can be re-written by copying each byte to memory and > back out again,
SQLite doesn't work on rows - it works on pages. A row will be contained within one or more pages. > WRT premature optimisation, I just need to keep the high memory > watermark as low as I can. You should have said that! SQLite has been used in some very low memory devices. You can purchase support if you need to get lower than stock SQLite. (For example they have a way you can omit the parser by having the prepared queries stored in the database.) 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. There are numerous existing APIs in SQLite for having fine grained control over memory allocation. http://www.sqlite.org/c3ref/c_config_getmalloc.html http://www.sqlite.org/c3ref/soft_heap_limit64.html http://www.sqlite.org/c3ref/memory_highwater.html Run your representative workload and see what numbers you get and tune accordingly. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8u8owACgkQmOOfHg372QRtAQCfeaSpuABYCGuk0MRrbNnwhVXb WoYAoMjKmpenzekb1Xvtz6IRAeQKycUA =4u/1 -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
