In addition to Stefans comment, the classic workaround for this requirement would be to create what Oracle calls a Function Based Index.
It's pretty similar to generated columns in SAP HANA and would allow the optimizer to leverage an existing index structure.
In SAP HANA the SQL optimizer is clever enough to figure out that there already is a pre-comuputed upper case version of the data in this case:
create column table bbb (name varchar(20)
, upper_name varchar(20) generated always as UPPER(name));
insert into bbb values ('Lars');
insert into bbb values ('Mara');
insert into bbb values ('Josh');
insert into bbb values ('Caroline');
select * from bbb;
NAME | UPPER_NAME |
Lars | LARS |
Mara | MARA |
Josh | JOSH |
Caroline | CAROLINE |
EXPLAIN PLAN FOR select * from bbb where upper(name) = upper('LaRs');
OPERATOR_NAME OPERATOR_DETAILS
COLUMN SEARCH BBB.NAME, BBB.UPPER_NAME (LATE MATERIALIZATION)
COLUMN TABLE FILTER CONDITION: BBB.UPPER_NAME = 'LARS'
As we see, the generated column is used here without any re-coding of the SQL statement.
Now, for the use of LIKE instead of equal, the feature works as well:
select * from bbb where upper(name) like '%AR%';
NAME | UPPER_NAME |
Lars | LARS |
Mara | MARA |
Caroline | CAROLINE |
EXPLAIN PLAN FOR select * from bbb where upper(name) like '%AR%';
OPERATOR_NAME OPERATOR_DETAILS
COLUMN SEARCH BBB.NAME, BBB.UPPER_NAME (LATE MATERIALIZATION)
COLUMN TABLE FILTER CONDITION: BBB.UPPER_NAME LIKE ''%AR%''
So, the old tricks still work with SAP HANA .
If this provides a much better performance is something to really test with actual data.
The huge difference in SAP HANA compared to row oriented DBMS is that the evaluation of the WHERE condition only works on the dictionary (the unique values of each column) and not on every single row.
Cheers, Lars