-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/12/11 20:10, Ivan Shmakov wrote: > The problem is that I have a table, each row holding something like 64 > bytes of data (of BLOB and INTEGER types), which don't seem too > compressible, but these rows themselves tend to be similar to each > other, so that the table could still be compressed as a whole, or in > chunks.
SQLite stores integers in a variable length encoding using (almost) the minimum bytes necessary. Consequently keeping your numbers as small as possible will help. You don't describe what your blobs are, but again encoding them in the shortest length possible will result in less data and redundancy making compression less significant. The page you linked to is a pretty good writeup on the subject. You can get good compression using CEROD but that doesn't allow making changes. Other than that you'll need to put something together yourself. You can compress your fields individually but then you'll only be able to equality comparisons (not ordering or partial matches). Using a precomputed dictionary can give good results even on short fields. Here is an example for English(ish) text: https://github.com/antirez/smaz Other than that you'll either need to work at the filesystem level or the SQLite page level as the article describes. Here is another compressor to consider: http://blosc.pytables.org/trac But I suggest you start at the beginning with an understanding of the SQLite file format: http://www.sqlite.org/fileformat2.html Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7+lnkACgkQmOOfHg372QRJXgCfUPPq2FE5i6Ve6TiZCa64kzU0 beIAoJMTw49+5Mo3AmNpAHC1qUpZpQKq =6iDD -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
