115 lines
3.6 KiB
Plaintext
115 lines
3.6 KiB
Plaintext
[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 <<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
|
|
|
|
{es} <<frozen-indices, frozen indices>> are a useful and powerful tool for hot/warm architecture introduced in {es} 6.6,
|
|
essentially by trading speed for memory.
|
|
{es-sql} supports frozen indices and similar to {es}, due to their performance characteristics, allows searches on them only
|
|
when explicitly told so by user - in other words, by default, frozen indices are not included in searches.
|
|
|
|
One can toggle the use of frozen indices through:
|
|
|
|
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. |