You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/esql/implicit-casting.asciidoc
+22-18Lines changed: 22 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@
5
5
<titleabbrev>Implicit casting</titleabbrev>
6
6
++++
7
7
8
-
Often users will input `date`, `ip`, `version`, `date_period` or `time_duration` as simple strings in their queries for use in predicates, functions, or expressions. {esql} provides <<esql-type-conversion-functions, type conversion functions>> to explicitly convert these strings into the desired data types.
8
+
Often users will input `date`, `date_period`, `time_duration`, `ip` or `version` as simple strings in their queries for use in predicates, functions, or expressions. {esql} provides <<esql-type-conversion-functions, type conversion functions>> to explicitly convert these strings into the desired data types.
9
9
10
10
Without implicit casting users must explicitly code these `to_X` functions in their queries, when string literals don't match the target data types they are assigned or compared to. Here is an example of using `to_datetime` to explicitly perform a data type conversion.
11
11
@@ -18,7 +18,10 @@ FROM employees
18
18
| LIMIT 1
19
19
----
20
20
21
-
Implicit casting improves usability, by automatically converting string literals to the target data type. This is most useful when the target data type is `date`, `ip`, `version`, `date_period` or `time_duration`. It is natural to specify these as a string in queries.
21
+
[discrete]
22
+
[[esql-implicit-casting-example]]
23
+
==== Implicit casting example
24
+
Implicit casting automatically converts string literals to the target data type. This allows users to specify string values for types like `date`, `date_period`, `time_duration`, `ip` and `version` in their queries.
22
25
23
26
The first query can be coded without calling the `to_datetime` function, as follows:
24
27
@@ -31,35 +34,36 @@ FROM employees
31
34
| LIMIT 1
32
35
----
33
36
34
-
[float]
35
-
=== Implicit casting support
37
+
[discrete]
38
+
[[esql-implicit-casting-supported-operations]]
39
+
==== Operations that support implicit casting
36
40
37
41
The following table details which {esql} operations support implicit casting for different data types.
Time spans represent intervals between two datetime values. There are currently two supported types of time spans:
9
+
10
+
* `DATE_PERIOD` specifies intervals in years, quarters, months, weeks and days
11
+
* `TIME_DURATION` specifies intervals in hours, minutes, seconds and milliseconds
12
+
13
+
A time span requires two elements: an integer value and a temporal unit.
14
+
15
+
Time spans work with grouping functions such as <<esql-bucket, BUCKET>>, scalar functions such as <<esql-date_trunc, DATE_TRUNC>> and arithmetic operators such as <<esql-add, `+`>> and <<esql-subtract, `-`>>. Convert strings to time spans using <<esql-to_dateperiod, TO_DATEPERIOD>>, <<esql-to_timeduration, TO_TIMEDURATION>>, or the cast operators `::DATE_PERIOD`, `::TIME_DURATION`.
When a time span is provided as a named parameter in string format, `TO_DATEPERIOD`, `::DATE_PERIOD`, `TO_TIMEDURATION` or `::TIME_DURATION` can be used to convert to its corresponding time span value for arithmetic operations like `+` and/or `-`.
56
+
[source, esql]
57
+
----
58
+
POST /_query
59
+
{
60
+
"query": """
61
+
FROM employees
62
+
| EVAL x = hire_date + ?timespan::DATE_PERIOD, y = hire_date - TO_DATEPERIOD(?timespan)
63
+
""",
64
+
"params": [{"timespan" : "1 day"}]
65
+
}
66
+
----
67
+
68
+
When a time span is provided as a named parameter in string format, it can be automatically converted to its corresponding time span value in grouping functions and scalar functions, like `BUCKET` and `DATE_TRUNC`.
69
+
[source, esql]
70
+
----
71
+
POST /_query
72
+
{
73
+
"query": """
74
+
FROM employees
75
+
| WHERE hire_date >= "1985-01-01T00:00:00Z" AND hire_date < "1986-01-01T00:00:00Z"
76
+
| STATS hires_per_week = COUNT(*) BY week = BUCKET(hire_date, ?timespan)
Copy file name to clipboardExpand all lines: docs/reference/how-to.asciidoc
+12-14Lines changed: 12 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,23 +1,21 @@
1
1
[[how-to]]
2
-
= How to
2
+
= Optimizations
3
3
4
-
[partintro]
5
-
--
6
-
Elasticsearch ships with defaults which are intended to give a good out of
7
-
the box experience. Full text search, highlighting, aggregations, and indexing
8
-
should all just work without the user having to change anything.
4
+
Elasticsearch's default settings provide a good out-of-box experience for basic operations like full text search, highlighting, aggregations, and indexing.
9
5
10
-
Once you better understand how you want to use Elasticsearch, however,
11
-
there are a number of optimizations you can make to improve performance
12
-
for your use case.
6
+
However, there are a number of optimizations you can make to improve performance for your use case.
13
7
14
-
This section provides guidance about which changes should and shouldn't be
15
-
made.
16
-
--
8
+
This section provides recommendations for various use cases.
0 commit comments