From 410bed2ab8c3864d7f34f9694d080adcaf446352 Mon Sep 17 00:00:00 2001 From: Tom Lane 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 178f073755..c572d0f90f 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 -- 2.40.0