I don't know why it works this way. It seems to be a property of the core PostgreSQL index machinery, not part of the pg_trgm module itself. If you really want to dig into, one of the PostgreSQL self-hosted mailing lists is probably a better place to ask.

Since you asked for alternative ways to do the search, one would be to separate the array and combine the expressions with AND:

select * from ilike_test where code ilike '%n/a%"' and code ilike '%03/02/2021#A%';

This will use the index, even though it is the "same thing" as the one that won't. The need to rewrite the query to account for the size of the array is not ideal.

Note that %n/a% has no useful trigrams, but I don't see a very feasible way to use that info in an automated fashion.

I don't know why it works this way. It seems to be a property of the core PostgreSQL index machinery, not part of the pg_trgm module itself. If you really want to dig into, one of the PostgreSQL self-hosted mailing lists is probably a better place to ask.

Since you asked for alternative ways to do the search, one would be to separate the array and combine the expressions with AND:

select * from ilike_test where code ilike '%n/a%"' and code ilike '%03/02/2021#A%';

This will use the index, even though it is the "same thing" as the one that won't. The need to rewrite the query to account for the size of the array is not ideal.

Note that %n/a% has no useful trigrams, but I don't see a very feasible way to use that info in an automated fashion. (it actually does have one usable trigram, a. But it is likely to be a very common one in your data)