Define DEPTABLE's KEY_VERTEX as INTEGER PRIMARY KEY
commitdcf66ebe06a08534e765f198d2c07ce7d85fe72b
authorTatiana Racheva <tatianaracheva@fb.com>
Fri, 28 Sep 2018 18:02:09 +0000 (28 11:02 -0700)
committerHhvm Bot <hhvm-bot@users.noreply.github.com>
Fri, 28 Sep 2018 18:14:45 +0000 (28 11:14 -0700)
tree90fdffd5d44309cecd87f705665fb06131a5c0d9
parent60fe34478373bd36194552a7e96eae169120ac34
Define DEPTABLE's KEY_VERTEX as INTEGER PRIMARY KEY

Summary:
This very small change decreases the size of the SQLite table by ~24% and improves the writing time in my very unscientific test by about 16%.

In SQLITE, INT is not the same as INTEGER. A table without an INTEGER PRIMARY KEY is created with a ROWID column. Specifying INTEGER PRIMARY KEY aliases ROWID to the user-created column. Additionally, [according to the SQLite documentation](https://www.sqlite.org/lang_createtable.html):

> Searching for a record with a specific rowid, or for all records with rowids within a specified range is around twice as fast as a similar search made by specifying any other PRIMARY KEY or indexed value.

At this time, this isn't terribly useful, because, as Jake pointed out to me, the cost of lookups is dwarved compared to the cost of reparsing and rechecking we do when looking up dependencies. I tested `--find-refs EntSchemaBase`, and the results were identical between the two states.

I suspect we defined the primary key as INT for DEPTABLE because INTEGER PRIMARY KEY used to be a 32-bit int and our KEY_VERTEX values were 64-bit. Our other tables define the primary key as INTEGER PRIMARY KEY already. The ROWID column is now also a 64-bit integer, so this change is safe. Again, [from the documentation](https://www.sqlite.org/autoinc.html):

> In SQLite, a column with type INTEGER PRIMARY KEY is an alias for the ROWID (except in WITHOUT ROWID tables) which is always a 64-bit signed integer

Reviewed By: ljw1004

Differential Revision: D10097554

fbshipit-source-id: d24fc7f64f03984520d1aa3ae9165918a2d3d006
hphp/hack/src/heap/hh_shared_sqlite.c