sgup432 commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2686285414
>Why do you find it sad?
It has more with the timing, as I was personally looking into improving the
query cache performance. 😁
I think its still pretty useful if done wel
jpountz commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2686261007
Why do you find it sad?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific
sgup432 commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2686255847
>OK. Would you like to open a PR?
Sure.
>For reference, I have been separately looking into reducing the importance
of the cache for good query performance and plan on
jpountz commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2686219104
OK. Would you like to open a PR?
For reference, I have been separately looking into reducing the importance
of the cache for good query performance and plan on making it disab
sgup432 commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2679778282
@jpountz Just checking if you’ve had a chance to look into this. As
mentioned, I believe dynamically adjusting `skip_factor` would be beneficial.
Additionally, we can also introduc
kkewwei commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2629365142
In query-sensitive scenarios, the dataset is very small, there is ample
remaining memory space. Users even want to cache all queries in memory, however
this cannot be achieved due t
sgup432 commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2629157954
We're considering adjusting the skip_factor limits dynamically to optimize
query cache usage when needed, especially when it's underutilized. By exposing
this as a dynamic cluster s
jpountz commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2629028239
In general I'm not a fan of exposing tuning knobs just because we can expose
them. Deciding when a clause is worth caching feels like something that Lucene
is the right decision mak
sgup432 commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2625954720
@jpountz If you think it is feasible via above approach, I can quickly raise
a PR on this with some UTs.
--
This is an automated message from the Apache Git Service.
To respond t
sgup432 commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2625661420
@jpountz Yeah I meant we could use something like AtomicReference to set it
dynamically in a thread safe way.
I meant harmless in a sense that it should be easy to implement via
jpountz commented on issue #14183:
URL: https://github.com/apache/lucene/issues/14183#issuecomment-2625648861
I am not entirely sure about the "harmless" part: this class is shared by
multiple threads so we would need to make sure that the value is updated in a
thread-safe way.
--
This i
11 matches
Mail list logo
