On Thu, Oct 29, 2015 at 7:09 PM, Jason H <jhihn at gmx.com> wrote: > This seems to be at odds with my understanding of "2.1 Record Format" of > the document. Given that it reads the row varint, which contains the length > of itself and the serial types of the columns, in order, it should be > completely able to skip the reading of unneeded columns. If I have 39,39,39 > as my header (excepting the length of header) I know I am dealing with 3 > text columns of 13 bytes each. If I want only the last column, I can then > seek(78), read(26). At no time did I need to read the prior two columns. > > Or did I misunderstand something? >
You seem to miss what Scott and Paul already explained, which is that SQLite is *paged*. The IO increment is the page (from 1/2K to 64K, with 1K, 2K, 4K, and 8K being popular choices I think). An SQLite file is a 100 byte header, and then N pages of a given size, determined at DB creation time. The sqlite_master table is the "root" page, which lists all tables, indexes, etc, and their starting page in that file. Look at the diagram to the right of http://www.sqlite.org/vfs.html (that I already sent). All IO is done by the *pager*, as it names indicate, it reads and writes *pages*. What you call "reading" column c1, skip c2, etc... is not "reading" per se. It's "decrypting" the memory block that represents a disk file page, that the pager read from file (actual IO of a whole page) and put in the page cache. it's a layered architecture with clean separation of concerns and responsibilities. --DD
