Type to search.

ES|QL metadata fields

Serverless

Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Serverless interfaces and procedures might differ from classic Elastic Stack deployments.

Stack

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

ES|QL can access metadata fields.

To access these fields, use the METADATA directive with the FROM source command. For example:

ES|QL
FROM index METADATA _index, _id

Stack Planned

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Planned

    We plan to add this functionality in a future Elastic Stack update. Subject to changes.

Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

The following fields identify the source that produced each row:

Metadata field Type Description
_class keyword What kind of source the row came from: index, view, subquery, or dataset.
_name keyword What the source is called: the index name on an index, the view name on a view, null on a subquery, and the dataset name on a dataset.

The following fields describe index and document metadata:

Metadata field Type Description
_id keyword Unique document ID.
_ignored keyword Names every field in a document that was ignored when the document was indexed.
_index keyword Index name.
_index_mode keyword Index mode. For example: standard, lookup, or logsdb.
_score float Query relevance score (when enabled). Scores are updated when using full text search functions. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability Planned We plan to add this functionality in a future Elastic Stack update. Subject to changes. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes. Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability Generally available This functionality is generally available and ready for production usage. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. A runtime search scores without BM25 and contributes to _score only after it runs.
_size integer Size in bytes of the original _source field when the mapper-size plugin is enabled.
_source Special _source type Original JSON document body passed at index time (or a reconstructed version if synthetic _source is enabled).
_version long Document version number
  • Most index metadata fields are available only for index sources. When a field is unavailable for a given source, its value is null. For source-specific behavior, refer to views, subqueries, and datasets.
  • The _source type is not supported by functions
  • Only the FROM command supports the METADATA directive
  • Once enabled, metadata fields work like regular index fields

Once enabled, metadata fields are available to subsequent processing commands, just like other index fields:

ES|QL
FROM ul_logs, apps METADATA _index, _version
| WHERE id IN (13, 14) AND _version == 1
| EVAL key = CONCAT(_index, "_", TO_STR(id))
| SORT id, _index
| KEEP id, _index, _version, key
id:long _index:keyword _version:long key:keyword
13 apps 1 apps_13
13 ul_logs 1 ul_logs_13
14 apps 1 apps_14
14 ul_logs 1 ul_logs_14

Similar to index fields, once an aggregation is performed, a metadata field will no longer be accessible to subsequent commands, unless used as a grouping field:

ES|QL
FROM employees METADATA _index, _id
| STATS max = MAX(emp_no) BY _index
max:integer _index:keyword
10100 employees
ES|QL
FROM products METADATA _score
| WHERE MATCH(description, "wireless headphones")
| SORT _score DESC
| KEEP name, description, _score
Tip

Refer to ES|QL for search for more information on relevance scoring and how to use _score in your queries.

A subquery or view returns null for _score when its output does not contain that field. This example combines rows from a subquery over languages with rows read directly from the same index:

ES|QL
FROM (FROM languages), languages METADATA _score
| WHERE MATCH(language_name, "English") OR MATCH(language_name, "French")
| EVAL has_score = _score > 0.0
| SORT has_score DESC NULLS LAST, language_code
| KEEP language_code, language_name, has_score
language_code:integer language_name:keyword has_score:boolean
1 English true
2 French true
1 English null
2 French null

The WHERE filter applies to both sources. The index rows return a score from MATCH. The subquery rows return null, because the subquery does not produce _score. The example only checks that each score is positive, because the score values depend on how many shards the index has. A descending sort places null values first by default, so use DESC NULLS LAST to keep rows without scores after scored rows, as shown in the example.

Using _source is useful when you want to retrieve most or all fields from a document.

You should consider retrieving _source instead of individual fields when:

  • You need several fields from a document, and most of them are text fields.
  • You have long text fields or geoshape fields in your documents.
  • You want the original document instead of the indexed values for your fields.
  • You have nested objects or arrays that you want to preserve in their original structure.

You might want to avoid retrieving _source when:

  • Your fields are stored as doc_values. doc_values access is faster than _source.
  • Your index uses synthetic source. Accessing _source in synthetic source mode has a performance penalty.
  • The text fields you need are stored fields.

Using _source or selecting fields are both valid options, but can have performance and data format implications that you should consider based on your use case.