On 29 Oct 2015, at 6:22pm, Jason H <jhihn at gmx.com> wrote: > Ah, so this is what I seem to have missed. The pages... This is unfortunate > as the read-heavy application won't likely benefit from SQLite. Only a small > fraction of the row data is used each query, and it seems like It'll have to > read the entire row (via the page) each time?
It will read the entire page each time. But the page is normally the size of a disk block, and the read is done in one operation: seek-to-sector-head and a read. It's the quickest possible thing to do and it happens very quickly indeed. It's actually as fast as seek-to-sector and read-a-few-bytes, because reading the entire block is how disk subsystems work internally. Also, because pages are quite big the page you want is probably already in memory. If you're not doing multi-access stuff it won't need to re-read. On 29 Oct 2015, at 6:32pm, Wade, William <bill.wade at dnvgl.com> wrote: > if a particular row requires twenty blocks of storage That happens almost never. The size of a page is a power of two between 512 and 65536 inclusive. When you create a new database, if you know you're going to have really long rows you tend to set a big page size. > and I > want to read a one-byte field that is in the twentieth block, all twenty > blocks will be read. Which is why you generally put small commonly-used columns before long text and blobs. Simon.
