123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111 |
- [role="xpack"]
- [testenv="basic"]
- [[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.
- [[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 <<freeze-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-rest>> 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.
|