Remove hppc from FieldMemoryStats #85240
Conversation
FieldMemoryStats is a simple wrapper around the association of a field to how much memory it is taking up. The size of this is not that large (not millions of keys), and there is lots of other overhead, so hppc classes are not really needed. This commit converts FieldMemoryStats to use a HashMap internally. relates elastic#84735
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
There was a problem hiding this comment.
Change looks correct to me but I think my only involvement in this area was to lift-and-shift the existing completion stats computation into a cache. I don't have a frame of reference to confirm that these maps are small enough to make this change without further investigation.
|
Perhaps @jpountz could take a look? This is used for tracking in fielddata and completion suggester. |
|
Completion stats should be good, there would usually be one or two completion fields per mapping, very unlikely more. Field data stats are more interesting. This is bounded by the number of keyword fields that users queried in a way that would require loading global ordinals. I'm confident that it would be ok with the new indexing strategy which bounds fields in mappings to fields that are actually useful. Filebeat/metricbeat indices can have fields in the order of several thousands, but it looks like we have logic to not put entries into the cache when the field does not exist in the Lucene index. So in both case, I'd expect these maps to have a number of entries in the order of a couple hundreds at most. |
5 participants
FieldMemoryStats is a simple wrapper around the association of a field
to how much memory it is taking up. The size of this is not that large
(not millions of keys), and there is lots of other overhead, so hppc
classes are not really needed. This commit converts FieldMemoryStats to
use a HashMap internally.
relates #84735