On Thu, Oct 6, 2016 at 9:25 AM, Hick Gunter <h...@scigames.at> wrote:
> SQLite compresses rows before storing and decompresses rows before > returning fields. BLOB fields are the most time consuming to process and so > should be placed at the end of the row. Often used fields - i.e. (foreign) > key fields - should be placed at the front of the row. This will help most > if your select field list is limited to the fields you actually need > instead of "*". > > Sorta, kinda, but not really. SQLite does not use a traditional data compression algorithm in storing row data, but it does "pack" rows into a compact format (including variable size integers). As such, a row's worth of data, as stored in the raw database, acts very similar to a compressed block of data... you have to read it from the start and can't directly jump to a field in a middle of it. This is the issue with column ordering; the data engine will only read and unpack the columns it needs, but it has to read and unpack the columns in the order they're defined until it gets all the columns it needs. This makes it generally better to put more frequently accessed and/or smaller values at the start of a row. -j _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
