A leading wildcard is one of the slowest things you can do with Lucene, and not a recommended practice, so either accept that it is slow or don't do it.
That said, there is a trick you can do with a reverse wildcard filter, but that's an expert-level feature and not recommended for average developers. -- Jack Krupansky On Mon, Feb 2, 2015 at 10:33 AM, Asit KAUSHIK <asitkaushikno...@gmail.com> wrote: > HI All > > We are working on a application logging project and this is one of the > search tables as below : > > > CREATE TABLE logentries ( > logentrytimestamputcguid timeuuid PRIMARY KEY, > context text, > date_to_hour bigint, > durationinseconds float, > eventtimestamputc timestamp, > ipaddress inet, > logentrytimestamputc timestamp, > loglevel int, > logmessagestring text, > logsequence int, > message text, > modulename text, > productname text, > searchitems map<text, text>, > servername text, > sessionname text, > stacktrace text, > threadname text, > timefinishutc timestamp, > timestartutc timestamp, > urihostname text, > uripathvalue text, > uriquerystring text, > useragentstring text, > username text > ); > > I have some queries on the design of this table : > > 1) Does a timeuuid is a good candidate for partition key as we would be > querying other fields with stargate-core full text project > > This table is actually be used for search like username like '*john' > likewise and uing this present model the performance is very slow . > > Please advise > > Regards > Asit > > > > > >
