From 821c7ac8334f54bcb3f290ae91f44421ce232716 Mon Sep 17 00:00:00 2001
From: epriestley <git@epriestley.com>
Date: Mon, 9 Oct 2017 17:01:56 -0700
Subject: [PATCH] For backup persitsence, mark the "common ngrams" table as a
 data table, not an index table

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".

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13000

Differential Revision: https://secure.phabricator.com/D18696
---
 .../config/schema/PhabricatorConfigSchemaSpec.php          | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/applications/config/schema/PhabricatorConfigSchemaSpec.php b/src/applications/config/schema/PhabricatorConfigSchemaSpec.php
index c451658682..8e67391b59 100644
--- a/src/applications/config/schema/PhabricatorConfigSchemaSpec.php
+++ b/src/applications/config/schema/PhabricatorConfigSchemaSpec.php
@@ -81,12 +81,15 @@ abstract class PhabricatorConfigSchemaSpec extends Phobject {
       $engine->getNgramsSchemaKeys(),
       $index_options);
 
+    // NOTE: The common ngrams table is not marked as an index table. It is
+    // tiny and persisting it across a restore saves us a lot of work garbage
+    // collecting common ngrams from the index after it gets built.
+
     $this->buildRawSchema(
       $engine->getApplicationName(),
       $engine->getCommonNgramsTableName(),
       $engine->getCommonNgramsSchemaColumns(),
-      $engine->getCommonNgramsSchemaKeys(),
-      $index_options);
+      $engine->getCommonNgramsSchemaKeys());
   }
 
   protected function buildRawSchema(