*** 34,40 ****
of SQLite would not be able to read or write databases that used
the new DATE type. Perhaps older versions of SQLite could interpret
the date column as a double to provide some measure of backwards
! compatability.
**PRIMARY KEY NOT NULL**
--- 34,40 ----
of SQLite would not be able to read or write databases that used
the new DATE type. Perhaps older versions of SQLite could interpret
the date column as a double to provide some measure of backwards
! compatibility.
**PRIMARY KEY NOT NULL**
***************
*** 46,56 ****
A great deal of space is wasted in an SQLite database if every column
is also included in the index. Index-only tables could alleviate this
! problem.
**Bitmap Indexes**
! When dealing with low-cardinality columns it would advantageous in
terms of both space and speed to support Bitmap Indexes rather
than b-tree based data structures.
--- 46,57 ----
A great deal of space is wasted in an SQLite database if every column
is also included in the index. Index-only tables could alleviate this
! problem. For larger in-memory tables this space saving ofter translates into avoiding SWAP usage, which in turn can improve performance dramatically.{linebreak}
! You can follow the progress of experimental implementation of this feature {link: http://www.sqlite.org/gfork/timeline here}.
**Bitmap Indexes**
! When dealing with low-cardinality columns it would be advantageous in
terms of both space and speed to support Bitmap Indexes rather
than b-tree based data structures.
***************
*** 58,70 ****
When dealing with high-selectivity columns it would be useful in terms of both disk I/O and space to support Hashed Indexes rather than b-tree based data structures. A side-effect of this choice would be that _in_order_ retrieval of this column could not use the index.
! **More Efficient Disk Format to Accomodate Random Access to BLOBs**
SQLite currently has to read the entire BLOB into memory to manipulate
! parts of it. It would be extremely conveniant to offer an API that
could quickly seek to any part of the BLOB without reading the leading
data first. It would also be faster and require less memory for the
! host application. (Note: This item seems to have been addressed by the new sqlite3_blob_open/read/write experimental API within the same backwords compatible sqlite3 disk format. Can anyone comment on the efficiency of the disk seeks within these blobs using sqlite3_blob_read and sqlite3_blob_write's iOffset parameter - is it random access?)
**Database Meta Data in Virtual Tables Instead of PRAGMAs**
--- 59,71 ----
When dealing with high-selectivity columns it would be useful in terms of both disk I/O and space to support Hashed Indexes rather than b-tree based data structures. A side-effect of this choice would be that _in_order_ retrieval of this column could not use the index.
! **More Efficient Disk Format to Accommodate Random Access to BLOBs**
SQLite currently has to read the entire BLOB into memory to manipulate
! parts of it. It would be extremely convenient to offer an API that
could quickly seek to any part of the BLOB without reading the leading
data first. It would also be faster and require less memory for the
! host application. (Note: This item seems to have been addressed by the new sqlite3_blob_open/read/write experimental API within the same backwards compatible sqlite3 disk format. Can anyone comment on the efficiency of the disk seeks within these blobs using sqlite3_blob_read and sqlite3_blob_write's iOffset parameter - is it random access?)
**Database Meta Data in Virtual Tables Instead of PRAGMAs**
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|