You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Torgeir Veimo <to...@gmail.com> on 2019/09/18 10:35:38 UTC
cost of lower() with sql2 LIKE operator
I'm wondering what the cost is of doing either lower(propname) or
lower(selectorname.*) when used with the SQL2 LIKE operator. Also, is
lower() strictly needed with the LIKE operator?
My limited testing show about a 10% slowdown when using
lower(propname), but it's just a very rudimentary test. I'd also
expect different results with property and lucene indexes?
--
-Tor
Re: cost of lower() with sql2 LIKE operator
Posted by Piotr TajduĊ <pi...@skg.pl>.
Not sure about "like", but when you have full text lucene index
(analyzed=true on indexed property) operator contains(selector,'value')
is case insensitive. In case of searching by property with operator =
(in both property and lucene index) search is case sensitive, so I
suppose query engine is index traversing values (there will be more
information in log if you enable debug or trace on
org.apache.jackrabbit.oak.query). You can also make function based index:
https://jackrabbit.apache.org/oak/docs/query/lucene.html#function-based-indexing
On 18.09.2019 12:35, Torgeir Veimo wrote:
> I'm wondering what the cost is of doing either lower(propname) or
> lower(selectorname.*) when used with the SQL2 LIKE operator. Also, is
> lower() strictly needed with the LIKE operator?
>
> My limited testing show about a 10% slowdown when using
> lower(propname), but it's just a very rudimentary test. I'd also
> expect different results with property and lucene indexes?
>