mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-09-21 09:10:48 +00:00
minor fixes
This commit is contained in:
parent
932589744c
commit
a23853c141
@ -93,7 +93,7 @@ ClickHouse has only one physical order, which is determined by `ORDER BY` clause
|
|||||||
- Cascade `UPDATE/DELETE` queries are not supported by the `MaterializeMySQL` engine.
|
- Cascade `UPDATE/DELETE` queries are not supported by the `MaterializeMySQL` engine.
|
||||||
- Replication can be easily broken.
|
- Replication can be easily broken.
|
||||||
- Manual operations on database and tables are forbidden.
|
- Manual operations on database and tables are forbidden.
|
||||||
- `MaterializeMySQL` is influenced by [optimize_on_insert](../../operations/settings/settings.md#optimize-on-insert) settings. There is a merge of data in the corresponding table in `MaterializeMySQL` database when a table in MySQL server changes.
|
- `MaterializeMySQL` is influenced by [optimize_on_insert](../../operations/settings/settings.md#optimize-on-insert) setting. The data is merged in the corresponding table in the `MaterializeMySQL` database when a table in the MySQL server changes.
|
||||||
|
|
||||||
## Examples of Use {#examples-of-use}
|
## Examples of Use {#examples-of-use}
|
||||||
|
|
||||||
|
@ -2594,7 +2594,7 @@ Default value: `16`.
|
|||||||
|
|
||||||
## optimize_on_insert {#optimize-on-insert}
|
## optimize_on_insert {#optimize-on-insert}
|
||||||
|
|
||||||
Do the same transformation for inserted block of data as if merge was done on this block (e.g. replacing, collapsing, aggregating...).
|
Enables or disables data transformation before the insertion, as if merge was done on this block (e.g. replacing, collapsing, aggregating...).
|
||||||
|
|
||||||
Possible values:
|
Possible values:
|
||||||
|
|
||||||
|
@ -59,7 +59,7 @@ A `SELECT` query can contain `DISTINCT`, `GROUP BY`, `ORDER BY`, `LIMIT`… Note
|
|||||||
|
|
||||||
The execution of [ALTER](../../../sql-reference/statements/alter/index.md) queries on materialized views has limitations, so they might be inconvenient. If the materialized view uses the construction `TO [db.]name`, you can `DETACH` the view, run `ALTER` for the target table, and then `ATTACH` the previously detached (`DETACH`) view.
|
The execution of [ALTER](../../../sql-reference/statements/alter/index.md) queries on materialized views has limitations, so they might be inconvenient. If the materialized view uses the construction `TO [db.]name`, you can `DETACH` the view, run `ALTER` for the target table, and then `ATTACH` the previously detached (`DETACH`) view.
|
||||||
|
|
||||||
Note that materialized view is influenced by [optimize_on_insert](../../../operations/settings/settings.md#optimize-on-insert) settings. There is a merge of data before the insertion in a view.
|
Note that materialized view is influenced by [optimize_on_insert](../../../operations/settings/settings.md#optimize-on-insert) setting. The data is merged before the insertion into a view.
|
||||||
|
|
||||||
Views look the same as normal tables. For example, they are listed in the result of the `SHOW TABLES` query.
|
Views look the same as normal tables. For example, they are listed in the result of the `SHOW TABLES` query.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user