[Docs] Add examples for FINAL

docs/en/sql-reference/statements/select/from.md

@@ -19,25 +19,51 @@ Subquery is another `SELECT` query that may be specified in parenthesis inside `
 
 ## FINAL Modifier
 
-When `FINAL` is specified, ClickHouse fully merges the data before returning the result and thus performs all data transformations that happen during merges for the given table engine.
+When `FINAL` is specified, ClickHouse fully merges the data before returning the result. This also performs all data transformations that happen during merges for the given table engine.
 
-It is applicable when selecting data from ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree, CollapsingMergeTree and VersionedCollapsingMergeTree tables.
+It is applicable when selecting data from from tables using the following table engines:
+- `ReplacingMergeTree`
+- `SummingMergeTree`
+- `AggregatingMergeTree`
+- `CollapsingMergeTree`
+- `VersionedCollapsingMergeTree`
 
 `SELECT` queries with `FINAL` are executed in parallel. The [max_final_threads](../../../operations/settings/settings.md#max-final-threads) setting limits the number of threads used.
 
-There are drawbacks to using `FINAL` (see below). 
-
 ### Drawbacks
 
-Queries that use `FINAL` are executed slightly slower than similar queries that do not, because:
+Queries that use `FINAL` execute slightly slower than similar queries that do not use `FINAL` because:
 
 - Data is merged during query execution.
-- Queries with `FINAL` read primary key columns in addition to the columns specified in the query.
+- Queries with `FINAL` may read primary key columns in addition to the columns specified in the query.
 
-`FINAL` requires additional compute and memory resources, as the processing that normally would occur at merge time must occur in memory at the time of the query. However, using FINAL is sometimes necessary in order to produce accurate results, and is less expensive than running `OPTIMIZE` to force a merge. It is also sometimes possible to use different queries that assume the background processes of the `MergeTree` engine haven’t happened yet and deal with it by applying aggregation (for example, to discard duplicates). If you need to use FINAL in your queries in order to get the required results, then it is okay to do so but be aware of the additional processing required.
+`FINAL` requires additional compute and memory resources because the processing that normally would occur at merge time must occur in memory at the time of the query. However, using FINAL is sometimes necessary in order to produce accurate results (as data may not yet be fully merged). It is less expensive than running `OPTIMIZE` to force a merge.
+
+As an alternative to using `FINAL`, it is sometimes possible to use different queries that assume the background processes of the `MergeTree` engine have not yet occurred and deal with it by applying an aggregation (for example, to discard duplicates). If you need to use `FINAL` in your queries in order to get the required results, it is okay to do so but be aware of the additional processing required.
 
 `FINAL` can be applied automatically using [FINAL](../../../operations/settings/settings.md#final) setting to all tables in a query using a session or a user profile.
 
+### Example Usage
+
+**Using the `FINAL` keyword**
+
+```sql
+SELECT x, y FROM mytable FINAL WHERE x > 1;
+```
+
+**Using `FINAL` as a query-level setting**
+
+```sql
+SELECT x, y FROM mytable WHERE x > 1 SETTINGS final = 1;
+```
+
+**Using `FINAL` as a session-level setting**
+
+```sql
+SET final = 1;
+SELECT x, y FROM mytable WHERE x > 1 SETTINGS final = 1;
+```
+
 ## Implementation Details
 
 If the `FROM` clause is omitted, data will be read from the `system.one` table.