Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Fix a typo in intern-v-extern-blob.html |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
c8b280b8eb0389b3c888403c50a7a6c9 |
User & Date: | drh 2013-05-01 00:14:55.678 |
Context
2013-05-01
| ||
11:02 | Fix typos in queryplanner-ng.html. (check-in: c9e2b500a2 user: drh tags: trunk) | |
00:14 | Fix a typo in intern-v-extern-blob.html (check-in: c8b280b8eb user: drh tags: trunk) | |
2013-04-30
| ||
22:20 | Updates to the next-generation-query-planner document. (check-in: 28554e7596 user: drh tags: trunk) | |
Changes
Changes to pages/intern-v-extern-blob.in.
︙ | ︙ | |||
8 9 10 11 12 13 14 | If you have a database of large BLOBs, do you get better read performance when you store the complete BLOB content directly in the database or is it faster to store each BLOB in a separate file and store just the corresponding filename in the database? </p> <p> | | | 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | If you have a database of large BLOBs, do you get better read performance when you store the complete BLOB content directly in the database or is it faster to store each BLOB in a separate file and store just the corresponding filename in the database? </p> <p> To try to answer this, we ran 49 test cases with various BLOB sizes and SQLite page sizes on a Linux workstation (Ubuntu circa 2011 with the Ext4 filesystem on a fast SATA disk). For each test case, a database was created that contains 100MB of BLOB content. The sizes of the BLOBs ranged from 10KB to 1MB. The number of BLOBs varied in order to keep the total BLOB content at about 100MB. (Hence, 100 BLOBs for the 1MB size and 10000 BLOBs for the 10K size and so forth.) SQLite version 3.7.8 was used. |
︙ | ︙ |