This takes result from the cache if present or otherwise resolves it bypassing the cache.

The issue here is that cache is only limited to 32 entries while the query touches 20 indices with 500 fields each.
In such cases (when the exists check is performed in the loop for each field) the result is not persisted anyways and is also quiet expensive to initialize.

fastNoCacheFieldExists instead only checks for field existence. This supposed to be cheaper as we need to find it in the first context in contrast to scanning all context to initialize the rest of the fields.

Please let me know if you believe we should reconsider cache size or if you see another way around it.

I'm fine with this way. Was the time mostly spent messing around with the hash map? I feel like a bunch of hash lookups isn't usually worth caching.

The choice of cache size 32 dates back to Costin's original work two years ago in c351235. I see no problem increasing the cache size, but also think your optimization is fine too.

Was the time mostly spent messing around with the hash map? I feel like a bunch of hash lookups isn't usually worth caching.

Here it was dominated by iterating (the blue bar on top of pink) in the profiling output.
To initialize the chace we need to loop all contexts, to reply to exists we optimistically need to find the first one or loop all if the field does not exists (should be rare I assume):

I think that while exists can short circuit the loop, the other checks cannot. So it makes sense to keep the loop and the cache for the other checks, but also to have a special case for exists. I wonder, however, how probable is it that the planner only calls for exists and not for the others?

We could merge this and see in a new profiling output if the same appears somewhere else.
If it does then this is not helpful and we would have to rethink the cache (maybe make it not expire entries and take into account circuit-breaker?)

I wonder, however, how probable is it that the planner only calls for exists and not for the others?

After thinking about it a little more:
In this case (benchmarks for from idx* | LIMIT something with 20 indices and 500 fields) we actually do not use SearchContextStats anywhere else, otherwise we would see initialization in other places already. We are likely use it in other cases so we might need to extend set of queries we benchmark.

The choice of cache size 32 dates back to Costin's original work two years ago in c351235. I see no problem increasing the cache size, but also think your optimization is fine too.