2018-09-04 21:54:10 +08:00
[role="xpack"]
2018-09-05 00:05:21 +08:00
[[sql-index-patterns]]
2019-06-11 17:04:00 +08:00
=== Index patterns
2018-09-04 21:54:10 +08:00
{es-sql} supports two types of patterns for matching multiple indices or tables:
2019-05-10 19:19:26 +08:00
[[sql-index-patterns-multi]]
2020-07-23 23:48:22 +08:00
[discrete]
2022-02-10 02:00:07 +08:00
==== {es} multi-target syntax
2018-09-04 21:54:10 +08:00
2021-07-01 00:24:42 +08:00
The {es} notation for enumerating, including or excluding <<api-multi-index,multi-target syntax>>
2018-09-04 21:54:10 +08:00
is supported _as long_ as it is quoted or escaped as a table identifier.
For example:
2019-06-01 01:03:41 +08:00
[source, sql]
2018-09-04 21:54:10 +08:00
----
2019-03-25 21:22:59 +08:00
include-tagged::{sql-specs}/docs/docs.csv-spec[showTablesEsMultiIndex]
2018-09-04 21:54:10 +08:00
----
Notice the pattern is surrounded by double quotes `"`. It enumerated `*` meaning all indices however
it excludes (due to `-`) all indices that start with `l`.
This notation is very convenient and powerful as it allows both inclusion and exclusion, depending on
the target naming convention.
2018-10-02 16:47:42 +08:00
The same kind of patterns can also be used to query multiple indices or tables.
For example:
2019-06-01 01:03:41 +08:00
[source, sql]
2018-10-02 16:47:42 +08:00
----
2019-03-25 21:22:59 +08:00
include-tagged::{sql-specs}/docs/docs.csv-spec[fromTablePatternQuoted]
2018-10-02 16:47:42 +08:00
----
NOTE: There is the restriction that all resolved concrete tables have the exact same mapping.
2022-01-06 03:01:01 +08:00
experimental:[] To run a <<modules-cross-cluster-search,{ccs}>>, specify a
cluster name using the `<remote_cluster>:<target>` syntax, where
`<remote_cluster>` maps to a SQL catalog (cluster) and `<target>` to a table
(index or data stream). The `<remote_cluster>` supports wildcards (`*`)
and `<target>` can be an index pattern.
For example:
[source, sql]
----
include-tagged::{sql-specs}/multi-cluster-with-security/multi-cluster-docs.csv-spec[fromQualifiedTableQuoted]
----
2019-05-10 19:19:26 +08:00
[[sql-index-patterns-like]]
2020-07-23 23:48:22 +08:00
[discrete]
2019-06-11 17:04:00 +08:00
==== SQL `LIKE` notation
2018-09-04 21:54:10 +08:00
The common `LIKE` statement (including escaping if needed) to match a wildcard pattern, based on one `_`
or multiple `%` characters.
Using `SHOW TABLES` command again:
2019-06-01 01:03:41 +08:00
[source, sql]
2018-09-04 21:54:10 +08:00
----
2019-03-25 21:22:59 +08:00
include-tagged::{sql-specs}/docs/docs.csv-spec[showTablesLikeWildcard]
2018-09-04 21:54:10 +08:00
----
2021-10-26 19:37:56 +08:00
The pattern matches all tables that start with `emp`.
2018-09-04 21:54:10 +08:00
This command supports _escaping_ as well, for example:
2019-06-01 01:03:41 +08:00
[source, sql]
2018-09-04 21:54:10 +08:00
----
2019-03-25 21:22:59 +08:00
include-tagged::{sql-specs}/docs/docs.csv-spec[showTablesLikeEscape]
2018-09-04 21:54:10 +08:00
----
Notice how now `emp%` does not match any tables because `%`, which means match zero or more characters,
has been escaped by `!` and thus becomes an regular char. And since there is no table named `emp%`,
an empty table is returned.
In a nutshell, the differences between the two type of patterns are:
2018-12-22 05:25:54 +08:00
[cols="^h,^,^"]
2018-09-04 21:54:10 +08:00
|===
2018-12-22 05:25:54 +08:00
s|Feature
s|Multi index
s|SQL `LIKE`
2018-09-04 21:54:10 +08:00
| Type of quoting | `"` | `'`
| Inclusion | Yes | Yes
| Exclusion | Yes | No
| Enumeration | Yes | No
| One char pattern | No | `_`
| Multi char pattern | `*` | `%`
| Escaping | No | `ESCAPE`
|===
Which one to use, is up to you however try to stick to the same one across your queries for consistency.
NOTE: As the query type of quoting between the two patterns is fairly similar (`"` vs `'`), {es-sql} _always_
requires the keyword `LIKE` for SQL `LIKE` pattern.
2019-05-10 19:19:26 +08:00
[[sql-index-frozen]]
2019-06-11 17:04:00 +08:00
=== Frozen Indices
2019-05-10 19:19:26 +08:00
2025-01-14 18:34:46 +08:00
By default, {es-sql} doesn't search <<frozen-indices,frozen indices>>. To
2021-05-13 00:54:20 +08:00
search frozen indices, use one of the following features:
2019-05-10 19:19:26 +08:00
2019-05-10 22:07:31 +08:00
dedicated configuration parameter::
2021-07-21 20:04:21 +08:00
Set to `true` properties `index_include_frozen` in the <<sql-search-api,SQL search API>> or `index.include.frozen` in the drivers to include frozen indices.
2019-05-10 19:19:26 +08:00
2019-05-10 22:07:31 +08:00
dedicated keyword::
Explicitly perform the inclusion through the dedicated `FROZEN` keyword in the `FROM` clause or `INCLUDE FROZEN` in the `SHOW` commands:
2019-05-10 19:19:26 +08:00
2019-06-01 01:03:41 +08:00
[source, sql]
2019-05-10 19:19:26 +08:00
----
2023-11-27 23:14:13 +08:00
include-tagged::{sql-specs}/docs/docs-frozen.csv-spec[showTablesIncludeFrozen]
2019-05-10 19:19:26 +08:00
----
2019-06-01 01:03:41 +08:00
[source, sql]
2019-05-10 19:19:26 +08:00
----
2023-11-27 23:14:13 +08:00
include-tagged::{sql-specs}/docs/docs-frozen.csv-spec[fromTableIncludeFrozen]
2019-05-10 19:19:26 +08:00
----
2021-10-26 19:37:56 +08:00
Unless enabled, frozen indices are completely ignored; it is as if they do not exist and as such, queries ran against them are likely to fail.