CQL filters `foo LIKE 'A%'` and `foo LIKE 'A%%'` should behaving consistently

CQL filters foo LIKE 'A%' and foo LIKE 'A%%' should behaving consistently

cql filter with foo LIKE 'A%'taking very very long and often timing out vs foo LIKE 'A%%' coming back instantly

Emilio Lahr-Vivaz @emilio.lahr-vivaz
3:16 PM
yeah, another thing i thought of is if geomesa isn't handling the wildcards right they might go to different indices, which could make a difference
we look for a trailing wildcard so if they're multiple that might not pass the check and go to z3 instead

Original JIRA Issue: https://geomesa.atlassian.net/browse/GEOMESA-3104

Key: GEOMESA-3104
Type: Bug
Priority: Major
Status: To Do
Resolution: Unresolved
Reporter: Austin Heyne
Created: Mon, 19 Jul 2021 16:19:28 -0400
Updated: Mon, 20 Sep 2021 08:54:41 -0400

Comments:

557058:48912df4-0004-4f90-9915-db26684ec006 (Wed, 21 Jul 2021 16:30:34 -0400):

The user reported that the query ‘like b%’ was using an attribute index while ‘like b%%’ was using the z3 index (without considering the attribute index).

Options involve a) working on the CBO b) having the user specify the index when querying via query params. Other suggestions?

557058:da7f6dfa-f0a1-468b-aec5-2cb61273feb5 (Mon, 20 Sep 2021 08:54:41 -0400):

% is like * right? so there’s no difference between ‘b%’ and ‘b%%’?

Start with CQL LIKE filter handling and the cost-based optimizer's choice between the attribute and Z3 indexes. Reproduce the foo LIKE 'A%' and foo LIKE 'A%%' queries and compare their index paths. Done means equivalent wildcard filters select an appropriate, consistent index and the timeout discrepancy is covered by regression tests.