Page MenuHomePhabricator

For backup persitsence, mark the "common ngrams" table as a data table, not an index table
ClosedPublic

Authored by epriestley on Oct 10 2017, 12:04 AM.
Tags
None
Referenced Files
F15396094: D18696.id44886.diff
Sun, Mar 16, 11:49 AM
F15334721: D18696.id44895.diff
Sat, Mar 8, 11:41 AM
Unknown Object (File)
Mon, Mar 3, 4:13 AM
Unknown Object (File)
Feb 9 2025, 9:05 PM
Unknown Object (File)
Jan 23 2025, 6:36 PM
Unknown Object (File)
Jan 21 2025, 4:06 PM
Unknown Object (File)
Jan 21 2025, 3:56 PM
Unknown Object (File)
Jan 21 2025, 12:06 PM
Subscribers
None

Details

Summary

Ref T13000. Garbage collecting common ngrams is slow because MySQL isn't all that great at deleting rows quickly. See PHI96, where it looks like it's going to take a week to GC ngrams for a ~million objects at a relatively conservative 0.15 threshold.

In the event of a restore, we can reduce the impact by persisting this table so the ngrams just don't get built when the reindex happens.

Test Plan

Viewed schema in Config, saw common ngrams tables marked as "Data" instead of "Index".

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable