Improve block loader fallback to source when source mode is synthetic.

[martijnvg]

Sometimes MappedFieldType#blockLoader(...) implementations fallback to an implementation that uses source. For example when a field has doc values or stored fields disabled, when ignore above or ignore above have been configured. Meaning it would read the _source field and then extract the relevant field out of it and use that as value to be returned by the block loader.

When synthetic source is enabled then instead the source gets computed from many doc value or stored fields, and then the relevant field gets extracted. This is very slow and this should be improved. The interesting part with synthetic source is that we don't need to compute the source in order to provided a fallback values as part of block loaders returned by MappedFieldType#blockLoader(...).

Synthetic source details relevant to block loader fallback logic:

• A field value exceeds the configured ignore above, then the value is stored in a separate stored field with the suffix _original.
• A field value is malformed, then the value gets stored in a stored field with the same name as is defined in the mapping. Regardless of whether stored fields are enabled.
• A field is has no stored or doc values fields. Then it gets stored in _ignored_source stored field.
• Ignored source is the fallback for synthetic source to avoid content in source getting lost. So for example if a an object field is disabled or number of allowed mapped fields is exceeded, the field values / content should end up in ignored source.

In case of synthetic source the block loaders returned by MappedFieldType#blockLoader(...) can be made aware if these details and instead of returning a BlockSourceReader based implementation, return an implementation that uses the right stored field or uses ignored source.

Tasks:

• Handle ignore above more efficiently.
• Handle ignore malformed more efficiently.
• Handle the reading field values that are stored in ignored source.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[martijnvg]

This POC (#114886) shows how falling back to ignore source can work.

[felixbarny]

Does this also cover cases where source filtering is used? In other words, when you only need to retrieve a specific field from _source, can we avoid synthesizing the full _source, which means fetching all fields?

[martijnvg]

This issue is in the context of synthetic source, but the idea is to avoid synthesizing the full source when only subset of fields is required. This isn't the case today.

[felixbarny]

My comment was also in context of synthetic source. Basically asking if we could also add an optimization to not re-construct the full _source when source filtering is used. Instead, just fetching fields that are required per the source filtering configuration. So if a doc has 100 fields, but the search request contains "_source": [ "foo", "bar" ], we could optimize to only fetch those two fields when synthesizing the source instead of synthesizing the full source and then filtering it afterwards.

[martijnvg]

Currently this issue is about es|ql's fallback mechanism to source when source mode is synthetic.

There is an issue for the search api: #94001
And @jimczi did relevant work recently that does source filtering correctly for synthetic source in the get api (#113827).

[jimczi]

I am currently focused on #114618 and was planning to resume and finish work for #113827 after that. @felixbarny are you interested by this change for the get or the search API? I am asking because get is much simpler to achieve than search which is why we started there.

[felixbarny]

I'm interested in _search. It's not something urgent. The question came up in the context of refactoring the APM UI to use fields. But some places still use _source with source filtering. Before the refactoring, there was a lot of usage of _source with filtering in the context of search. So I was suspecting that there may be other places that make use of _search + filtering that would have a performance regression when using synthetic _source.