It can already be downloaded and is quite exciting.
Yes there would be a space-saving, but it is rather minimal. The real advantage is removing one complete lookup reference cycle from
a Query where the Primary key is anything other than an INTEGER-typed primary key.
When you have an INTEGER primary key, and specifies it in a lookup (ex. ... WHERE ID=5) the BTREE implementation simply branch down
the tree to the exact leaf - (let's call this a reference cycle).
So for another type of index, which to my understanding even include INT typed Primary keys (along with TEXT, NUMERIC, etc)
[*Citation Needed] the old implementation had to store the BTREE for the index, find it's node in the Tree, obtain from it a rowid,
then run down that tree to find the data leaf. [This may be a simplified version of the actual events]. So NOW, we can traverse a
BTREE for the real Primary key directly to a data leaf (or page-link if the data is large) in stead of invoking another reference cycle.
Neat, isn't it?
Of course all those SQLite DB managers who depended on RowID for editing values etc. now need to take careful note of this
possibility that future tables may not sport any RowIDs and referencing it may fail. (or does it?)
I wonder if the Devs will consider adding a Pragma or a column in the table_info(tbl) Pragma to indicate this somehow, as opposed to
having to parse the table create sql to learn whether a rowid is available or not - OR - better even, make the word "rowid" (and/or
its various forms) become an alias for the Primary key (as opposed to the other way round) where tables have primary keys. Might
even make things like (... WHERE RowID LIKE "John%") possible.
These are just musing for now, anyone else have any thoughts?
On 2013/11/15 13:14, Pepijn Van Eeckhoudt wrote:
I've been looking into the upcoming 'without rowid' feature implementation to assess if it will have any impact on the OGC
GeoPackage specification.
One of the things I was wondering is what the intended use case of this feature is. Does it provide a performance boost and/or
space savings? If not, when would you use this?
Regards,
Pepijn
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
