From 410bed2ab8c3864d7f34f9694d080adcaf446352 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 15 Apr 2013 12:49:29 -0400
Subject: [PATCH] Improve GiST index search performance for trigram regex
queries.
The initial coding just descended the index if any of the target trigrams
were possibly present at the next level down. But actually we can apply
trigramsMatchGraph() so as to take advantage of AND requirements when there
are some. The input data might contain false positive matches, but that
can only result in a false positive result, not false negative, so it's
safe to do it this way.
Alexander Korotkov
---
contrib/pg_trgm/trgm_gist.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/contrib/pg_trgm/trgm_gist.c b/contrib/pg_trgm/trgm_gist.c
index 178f073755b..c572d0f90f7 100644
--- a/contrib/pg_trgm/trgm_gist.c
+++ b/contrib/pg_trgm/trgm_gist.c
@@ -401,18 +401,24 @@ gtrgm_consistent(PG_FUNCTION_ARGS)
len = ARRNELEM(qtrg);
trgm *ptr = GETARR(qtrg);
BITVECP sign = GETSIGN(key);
+ bool *check;
- /* descend only if at least one trigram is present */
- res = false;
+ /*
+ * GETBIT() tests may give false positives, due to limited
+ * size of the sign array. But since trigramsMatchGraph()
+ * implements a monotone boolean function, false positives
+ * in the check array can't lead to false negative answer.
+ * So we can apply trigramsMatchGraph despite uncertainty,
+ * and that usefully improves the quality of the search.
+ */
+ check = (bool *) palloc(len * sizeof(bool));
for (k = 0; k < len; k++)
{
CPTRGM(((char *) &tmp), ptr + k);
- if (GETBIT(sign, HASHVAL(tmp)))
- {
- res = true;
- break;
- }
+ check[k] = GETBIT(sign, HASHVAL(tmp));
}
+ res = trigramsMatchGraph(cache->graph, check);
+ pfree(check);
}
}
else
--
GitLab