Maybe I'm missing something here, but there should be an interface to page a blob into memory. Especially for large blobs, this would make sense to me to not load them into memory at once.
If sqlite doesn't provide this already, it would probably make a lot of sense to include this functionality or to propagate it to the SQL layer. Mike >--- [EMAIL PROTECTED] wrote: >> Felix Schwarz <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > I have just discovered these old message on the SQLite Yahoo! Group: >> > >> > http://groups.yahoo.com/group/sqlite/message/2115 >> > http://groups.yahoo.com/group/sqlite/message/2117 >> > >> > This does sound very interesting! If I simply want to store binary >> > data that I want to access via an index number again (and do this >> > real quick), how big is the difference between using SQLite or its >> > btree functions directly? >> > >> >> I'm guessing that you will not see a significant performance >> improvement over using prepared statements in the SQL interface >> and a table like this: >> >> CREATE TABLE storage( >> id INTEGER PRIMARY KEY, >> data BLOB >> ); > >If you read the blob all in at once, true. >But doesn't sqlite3BtreeData() allows you to read a partial chunk of >data from the blob at an arbitrary offset? This could be advantageous >if you are dealing with multi-megabyte blobs and do not require/want >the entire blob in memory at once. > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com
