On Sun, Mar 18, 2018 at 4:48 PM, Richard Hipp <[email protected]> wrote: > These APIs support the concept of using small databases (small enough > to fit in memory) as a container for passing information around.
I very much like the concept. Thank you for this addition. But then, this is begging for a JSON1-like extension to access an SQLite DB inside a blob-column :) Sure, that's denormalized, we all know that happens (case in point JSON1) and for some types of data like arrays (whose elements have no "natural keys"), that would be one way. But then the 100 bytes SQLite header, 1-page sqlite_master (for 1 table to store something into), and at east 1 page for that table puts the overhead of the first byte of data to 100+512+512 = 1124 byte, too much for smallish data... > On 3/18/18, Olivier Mascia <[email protected]> wrote: > > Is the serialized format quite compact, or full > > of void unused space on 'pages'? (that obviously a good external > compression > > would get rid of). Or said differently, how far or close is the > serialized > > format to the on-disk SQLite file format? > > The serialization format is exactly the on-disk format. So you can > write the serialization into a file, then open that file as a > database. Or you can read a file off of disk into memory then > "deserialize" that blob into a database. > > Normally when you open a :memory: database, the pages are spread out > in memory at arbitrary locations. But with sqlite3_deserialize(), > SQLite keeps all the pages in one contiguous blob. > > As for size, I have found that using page_size=512 gives maximum space > efficiency. > I guess Olivier's "compactness" question could also be viewed in terms of "empty" pages after deletes, or partially empty pages, i.e. are in-memory DBs always implicitly in a "vaccumed" state, w/o any "unused" pages in the middle? --DD _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
