Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 410bed2

Browse files
committed
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
1 parent e08fdf1 commit 410bed2

File tree

1 file changed

+13
-7
lines changed

1 file changed

+13
-7
lines changed

contrib/pg_trgm/trgm_gist.c

+13-7
Original file line numberDiff line numberDiff line change
@@ -401,18 +401,24 @@ gtrgm_consistent(PG_FUNCTION_ARGS)
401401
len = ARRNELEM(qtrg);
402402
trgm *ptr = GETARR(qtrg);
403403
BITVECP sign = GETSIGN(key);
404+
bool *check;
404405

405-
/* descend only if at least one trigram is present */
406-
res = false;
406+
/*
407+
* GETBIT() tests may give false positives, due to limited
408+
* size of the sign array. But since trigramsMatchGraph()
409+
* implements a monotone boolean function, false positives
410+
* in the check array can't lead to false negative answer.
411+
* So we can apply trigramsMatchGraph despite uncertainty,
412+
* and that usefully improves the quality of the search.
413+
*/
414+
check = (bool *) palloc(len * sizeof(bool));
407415
for (k = 0; k < len; k++)
408416
{
409417
CPTRGM(((char *) &tmp), ptr + k);
410-
if (GETBIT(sign, HASHVAL(tmp)))
411-
{
412-
res = true;
413-
break;
414-
}
418+
check[k] = GETBIT(sign, HASHVAL(tmp));
415419
}
420+
res = trigramsMatchGraph(cache->graph, check);
421+
pfree(check);
416422
}
417423
}
418424
else

0 commit comments

Comments
 (0)