Despite some experimenting, i'm unable to find any relevant effect of

creating an index for the keys table on apropos(1) search times;
apparently, adding that index was premature optimization in the first
place; so, stop adding that index.

Its root gone, the following evil is reduced (/usr/share/man on my notebook)
 - DB build time with -Q goes down by 15%, now at 1/3 of makewhatis
 - DB size with -Q goes down by 35%, now at 3.5x of makewhatis
 - full DB build time goes down by 12%, now at 2.1x of makewhatis
 - full DB size goes down by 42%, now at 11.5x of makewhatis

1 files changed, 2 insertions, 4 deletions

diff --git a/mandocdb.c b/mandocdb.c
index 90351637..f24862d7 100644
--- a/mandocdb.c
+++ b/mandocdb.c
@@ -1,4 +1,4 @@
-/*	$Id: mandocdb.c,v 1.107 2014/01/06 20:53:40 schwarze Exp $ */
+/*	$Id: mandocdb.c,v 1.108 2014/01/18 08:19:18 schwarze Exp $ */
 /*
  * Copyright (c) 2011, 2012 Kristaps Dzonsons <kristaps@bsd.lv>
  * Copyright (c) 2011, 2012, 2013, 2014 Ingo Schwarze <schwarze@openbsd.org>
@@ -1924,9 +1924,7 @@ dbopen(int real)
 	      " \"pageid\" INTEGER NOT NULL REFERENCES mpages(id) "
 		"ON DELETE CASCADE,\n"
 	      " \"id\" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL\n"
-	      ");\n"
-	      "\n"
-	      "CREATE INDEX \"key_index\" ON keys (key);\n";
+	      ");\n";
 
 	if (SQLITE_OK != sqlite3_exec(db, sql, NULL, NULL, NULL)) {
 		exitcode = (int)MANDOCLEVEL_SYSERR;