On Tue, Mar 5, 2013 at 4:05 PM, Richard Hipp <d...@sqlite.org> wrote: > Both implementations allow for reading just the prefix of the content blob > in order to access earlier fields of a table, leaving the tail of the blob > unread on disk.
This information sparked a bit of a debate among my colleagues, because since SQLite's back-end is paged, some of them assumed that pages corresponding (entirely) to un-selected (blob) columns would be skipped/seeked over, thus avoiding to be read from disk, even if followed by other columns that are selected. Am I reading you correctly that this assumption is incorrect? Concretely, assuming a table with a few scalar columns i, t, r (thus fairly small in byte size), a couple large to very large blob columns, b1, b2, followed by a couple scalar columns again e1, e2 (at the end by "mistake" or as the result of a add-column schema upgrade). * That table contains a single row, starting on page 5. the i, t, r values/cells for that row are on that page. * The b1, b2 blobs of that row spread from page 5 to 875. * The trailing e1, e2 scalars of that row as also on page 875. If I select i, t, r, e1, e2, is SQLite reading the two pages (5, 875), or the whole range (5 - 875)? Thanks, --DD PS: The table described above really exists in our software, is often a large one ( > 1 GB, mostly because of the blobs), and the debate is whether it's really worth to reorder the columns close to a release. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
