[role="xpack"]
[[sql-index-patterns]]
=== Index patterns

{es-sql} supports two types of patterns for matching multiple indices or tables:

[[sql-index-patterns-multi]]
[discrete]
==== {es} multi-index

The {es} notation for enumerating, including or excluding <<api-multi-index,multi-target syntax>>
is supported _as long_ as it is quoted or escaped as a table identifier.

For example:

[source, sql]
----
include-tagged::{sql-specs}/docs/docs.csv-spec[showTablesEsMultiIndex]
----

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.

The same kind of patterns can also be used to query multiple indices or tables.

For example:

[source, sql]
----
include-tagged::{sql-specs}/docs/docs.csv-spec[fromTablePatternQuoted]
----

NOTE: There is the restriction that all resolved concrete tables have the exact same mapping.

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]
----

[[sql-index-patterns-like]]
[discrete]
==== SQL `LIKE` notation

The common `LIKE` statement (including escaping if needed) to match a wildcard pattern, based on one `_`
or multiple `%` characters.

Using `SHOW TABLES` command again:

[source, sql]
----
include-tagged::{sql-specs}/docs/docs.csv-spec[showTablesLikeWildcard]
----

The pattern matches all tables that start with `emp`.

This command supports _escaping_ as well, for example:

[source, sql]
----
include-tagged::{sql-specs}/docs/docs.csv-spec[showTablesLikeEscape]
----

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:

[cols="^h,^,^"]
|===
s|Feature
s|Multi index
s|SQL `LIKE`

| 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.

[[sql-index-frozen]]
=== Frozen Indices

By default, {es-sql} doesn't search <<unfreeze-index-api,frozen indices>>. To
search frozen indices, use one of the following features:

dedicated configuration parameter::
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.

dedicated keyword::
Explicitly perform the inclusion through the dedicated `FROZEN` keyword in the `FROM` clause or `INCLUDE FROZEN` in the `SHOW` commands:

[source, sql]
----
include-tagged::{sql-specs}/docs/docs.csv-spec[showTablesIncludeFrozen]
----


[source, sql]
----
include-tagged::{sql-specs}/docs/docs.csv-spec[fromTableIncludeFrozen]
----

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.
