: updating your index between queries, so you may be reloading : your cache every time. Are you updating or adding documents : between queries and if so, how? : : If this is vaguely on target, have you tried firing up warmup queries : after you update your index that involve your timestamp?
based on the usecase, i'm not sure that that will really help -- it sounds like the range query is alwasy based on the exact timestamp of the most recent doc from the lat time this particular query was run -- which means by definition that that timestamp changes every time the query is run, so caching it is useless. skimming the thread, it's seems like the OP isn't using TrieDateField (when asked if he was, he posted a followup about precision if he did use it -- implying he is not currently). Switching to TrieDateField is probably the only thing improvement possibly to make a significant differnece in speeding up these one time queries. i've also seen no explanation of how big the index is, or what the OP's definition of "slow" is (how fast are the queries with and w/o these filters?). that type of information is fairly critical to being able to offer performance suggestions. I'm also suspicious of hte entire line of questioning -- it smells like there might be an XY Problem here. knowing what the ultimate goal that lead to this timestamp based filter query appraoch might help us suggest an alternate/better/faster solution. -Hoss
