Thanks, all! Sorry for the delayed response. I ran into an SD card reading issue that I'm still trying to solve (multiple block reading), and I've worked around it for now to keep trying to make progress on the database.
I have switched to memsys3 and the 60 KB heap seems sufficient for now to run the stated query as well as open a temporary memory table for inquiries to look for new devices. I had to put my own, global, mutex around every access to SQLite since I don't seem to be having much luck with SQLite's built in mutexing (it's claiming database corruption / malformed schema when I access it from the Bluetooth thread). Once I put a mutex around every call to SQLite I got back in business. I suppose I could alternatively restructure the application so SQLite is always only called from a single thread, but that sounds about as tricky. Here is my current schema: CREATE TABLE `Pairings` ( `Address` blob, `UserID` integer, `ClassOfDevice` blob, `ConnectPriority` integer, `Name` text, PRIMARY KEY(Address) ) CREATE TABLE `LinkKeys` ( `Address` blob, `LinkKey` blob, PRIMARY KEY(Address) ) As per Bluetooth specification, Address is always 6 bytes, LinkKey is always 16, ClassOfDevice always 3. I know, not a whole lot. I could maybe get away with putting LinkKey as another column in Pairings, but this relational setup is a small example of what might end up happening for other types of data I'd like to store. (If Bluetooth pairings were the only thing, this might be overkill and I'd just create a flat structure and store it directly in EEPROM or something like that) As I have attempted to start familiarizing myself with how memsys3 works differently than memsys5, one thing does worry me - memsys3 comes with the caveat that there is no mathematical guarantee against fragmentation. So, I guess the next question would be...how do I know when it's fragmented, as opposed to when it's simply run plumb out as memsys5 did under this condition? Is there a clean way to wipe the memory and start over again when this happens? (e.g. close database connection, reopen, voila heap magically starts over as if first started, no more fragmentation) I have set my default page size to 512 and will rebuild my database and see where I end up next. I've defined about as many SQLITE_OMIT_* things as I can think of that I won't need (except the ones that would require regenerating the amalgamation source). Code space is getting a little tight (770kb of 1mb used so far), but the main thing is memory allocation at the moment (between SQLite and Bluetooth, both of which need dynamic alloc/free, I've got half the RAM dedicated to them). Code space can be reduced in a couple of other ways if I need, and as a last resort I'll regenerate amalgamation source with a few more omit flags. Are there any omit/other preprocessor defines that are particularly helpful for reducing memory usage? Many thanks! I appreciate all the responses! On Mon, Oct 20, 2014 at 7:20 PM, Richard Hipp <d...@sqlite.org> wrote: > On Mon, Oct 20, 2014 at 5:21 PM, Dennis Field <f...@xibase.com> wrote: > > > > > When I initialize SQLite, I am instructing it to take a single heap for > > memsys5 of 60 * 1024. > > > > Have you tried using memsys3 instead of memsys5? Memsys3 can be more > memory-efficient. > > You might also want to disable LOOKASIDE memory, and set you default pages > size to 512 bytes. > > What does your schema look like? > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
