Saving a minimum of 7 bytes I meant.

From: x<mailto:tam118...@hotmail.com>
Sent: 10 August 2017 12:19
To: SQLite mailing list<mailto:sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] Packing integer primary key with field bits

Thanks for the replies. I’m not sure I agree with Gunter and Ryan though. I’m 
thinking about this more from the gain in speed rather than saving space.

To clarify, I’m suggesting replacing a compound key (made up of several integer 
cols) with an integer primary key (which sqlite will use rather than the row 
id). I have done my homework on this so I’m familiar with Gunter’s points 
regarding ‘between’ and ‘high end bits’ but will the between on a single 
integer key not be faster than matching on the first m fields of an n compound 
key? If an index is needed on any non-high bit col an expression index would 
work just as fast for lookups (I suppose inserts would be slower). The savings 
on space would contribute to the speed as each disk read would contain more 
records.

Even forgetting about keys, if you packed say 8 columns into one int64 column 
would you not be saving a minimum of 7 bits?


From: Hick Gunter<mailto:h...@scigames.at>
Sent: 10 August 2017 10:53
To: 'SQLite mailing list'<mailto:sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] Packing integer primary key with field bits

For the sake of the argument, let's try to devise a workable scheme for such an 
undertaking:

Lets assume you have a 32-bit "real rowid" and four 8-bit "value" fields.

How to distribute these in the 64-bit rowid?

Rrid low = MSB | v1 | v2 | v3 | v4 | r1r2r3r4 | LSB or
Rrid high =  MSB | r1r2r3r4 | v1 | v2 | v3 | v4 | LSB?

Let's try to select a row by real rowid:

SELECT id FROM t WHERE id & 0xffff = 1234;

There is no index on "id & 0xffff" so this translates into a full table scan 
(even if limited to one row, it still requires on average 1/2 of the rows to be 
read). Creating an index is no option because we are trying to save space, 
remember?

SELECT id FROM t WHERE id BETWEEN (1234<<32) and (1234<<32 + 0xffff);

This only works with "real rowid high" ("real rowid low" requires 2^^32 ranges 
to work) and the lookup is fast, but the endpoints should better be calculated 
in the calling program.

So for a reasonably fast lookup by "real rowid", it needs to occupy the most 
significant bits.

Trying to select by one the values, by extension of the arguments given, will 
either be a nightmare, default to a full table scan or require a covering index 
(which requires more disk space than the 4-12 bytes per record we have "saved").

Additionally, if any of the statements returns more than one row for any "real 
rowid" then your table is shot up beyond repair...

-----Ursprüngliche Nachricht-----
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von x
Gesendet: Donnerstag, 10. August 2017 09:45
An: sqlite-users@mailinglists.sqlite.org
Betreff: [sqlite] Packing integer primary key with field bits

As in cramming numerous integer columns into a 64 bit integer.

Does anyone do this?

Is the speed gain worth the additional confusion of extracting the columns from 
the key?

How is it best accomplished (virtual table maybe)?
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___________________________________________
 Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: h...@scigames.at

This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is confidential, 
privileged or legally protected. Any unauthorized use or dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the sender by return e-mail message and 
delete all copies of the original communication. Thank you for your cooperation.


_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to