ES|QL metadata fields
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability 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.
Serverless
Generally available
Stack
Generally available
ES|QL can access metadata fields.
To access these fields, use the METADATA directive with the FROM source command. For example:
FROM index METADATA _index, _id
The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability 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.
Stack
Planned
Planned
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
_sourcetype is not supported by functions - Only the
FROMcommand supports theMETADATAdirective - Once enabled, metadata fields work like regular index fields
Once enabled, metadata fields are available to subsequent processing commands, just like other index fields:
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:
FROM employees METADATA _index, _id
| STATS max = MAX(emp_no) BY _index
| max:integer | _index:keyword |
|---|---|
| 10100 | employees |
FROM products METADATA _score
| WHERE MATCH(description, "wireless headphones")
| SORT _score DESC
| KEEP name, description, _score
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:
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_valuesaccess is faster than _source. - Your index uses synthetic source. Accessing _
sourcein 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.