mirror of
https://we.phorge.it/source/phorge.git
synced 2024-12-25 15:00:58 +01:00
1de130c9f5
Summary: Ref T13000. This adds support for tracking "common" ngrams, which occur in too many documents to be useful as part of the ngram index. If an ngram is listed in the "common" table, it won't be written when indexing documents, or queried for when searching for them. In this change, nothing actually writes to the "common" table. I'll start writing to the table in a followup change. Specifically, I plan to do this: - A new GC process updates the "common" table periodically, by writing ngrams which appear in more than X% of documents to it, for some value of X, if there are at least a minimum number of documents (maybe like 4,000). - A new GC process deletes ngrams that have been added to the common table from the existing indexes. Hopefully, this will pare down the ngrams index to something reasonable over time without requiring any manual tuning. Test Plan: - Ran some queries and indexes. - Manually inserted ngrams `xxx` and `yyy` into the ngrams table, searched and indexed, saw them ignored as viable ngrams for search/index. Reviewers: amckinley Reviewed By: amckinley Maniphest Tasks: T13000 Differential Revision: https://secure.phabricator.com/D18672
7 lines
317 B
SQL
7 lines
317 B
SQL
CREATE TABLE {$NAMESPACE}_owners.owners_package_fngrams_common (
|
|
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
|
|
ngram CHAR(3) NOT NULL COLLATE {$COLLATE_TEXT},
|
|
needsCollection BOOL NOT NULL,
|
|
UNIQUE KEY `key_ngram` (ngram),
|
|
KEY `key_collect` (needsCollection)
|
|
) ENGINE=InnoDB, COLLATE {$COLLATE_TEXT};
|