Give the mlinks and keys tables a pageid index,
authorschwarze <schwarze@openbsd.org>
Wed, 16 Apr 2014 18:59:38 +0000 (18:59 +0000)
committerschwarze <schwarze@openbsd.org>
Wed, 16 Apr 2014 18:59:38 +0000 (18:59 +0000)
as suggested by jeremy@ and espie@.

The mlinks index speeds up basic apropos(1) searches by around 30%
because it speeds up the final SELECT FROM mlinks query by about 95%.
For large result sets, the overall speedup gets even larger, in the
extreme case of "apropos Nd~." by more than 90%.
The keys index finally makes the apropos(1) -O option usable: It no longer
incurs relevant extra cost, while in the past it was embarrassingly slow.

This comes at a cost:  Total database build times grow by about 5%,
and each index adds about 10% database size with -Q.  I consider that
acceptable in view of the huge apropos(1) performance gains.
The -Q database for /usr/share/man still remains below 1 MB.

usr.bin/mandoc/mandocdb.c

index 2afe01b..2e1a10b 100644 (file)
@@ -1,4 +1,4 @@
-/*     $Id: mandocdb.c,v 1.92 2014/04/13 22:02:54 schwarze Exp $ */
+/*     $Id: mandocdb.c,v 1.93 2014/04/16 18:59:38 schwarze Exp $ */
 /*
  * Copyright (c) 2011, 2012 Kristaps Dzonsons <kristaps@bsd.lv>
  * Copyright (c) 2011, 2012, 2013, 2014 Ingo Schwarze <schwarze@openbsd.org>
@@ -2174,6 +2174,7 @@ create_tables:
              " \"pageid\" INTEGER NOT NULL REFERENCES mpages(id) "
                "ON DELETE CASCADE\n"
              ");\n"
+             "CREATE INDEX mlinks_pageid_idx ON mlinks (pageid);\n"
              "\n"
              "CREATE TABLE \"names\" (\n"
              " \"bits\" INTEGER NOT NULL,\n"
@@ -2187,7 +2188,8 @@ create_tables:
              " \"key\" TEXT NOT NULL,\n"
              " \"pageid\" INTEGER NOT NULL REFERENCES mpages(id) "
                "ON DELETE CASCADE\n"
-             ");\n";
+             ");\n"
+             "CREATE INDEX keys_pageid_idx ON keys (pageid);\n";
 
        if (SQLITE_OK != sqlite3_exec(db, sql, NULL, NULL, NULL)) {
                exitcode = (int)MANDOCLEVEL_SYSERR;