DETACH Statement

Makes the server “forget” about the existence of a table, a materialized view, or a dictionary.

Syntax

  1. DETACH TABLE|VIEW|DICTIONARY [IF EXISTS] [db.]name [ON CLUSTER cluster] [PERMANENTLY]

Detaching does not delete the data or metadata of a table, a materialized view or a dictionary. If an entity was not detached PERMANENTLY, on the next server launch the server will read the metadata and recall the table/view/dictionary again. If an entity was detached PERMANENTLY, there will be no automatic recall.

Whether a table or a dictionary was detached permanently or not, in both cases you can reattach them using the ATTACH query.
System log tables can be also attached back (e.g. query_log, text_log, etc). Other system tables can’t be reattached. On the next server launch the server will recall those tables again.

ATTACH MATERIALIZED VIEW does not work with short syntax (without SELECT), but you can attach it using the ATTACH TABLE query.

Note that you can not detach permanently the table which is already detached (temporary). But you can attach it back and then detach permanently again.

Also you can not DROP the detached table, or CREATE TABLE with the same name as detached permanently, or replace it with the other table with RENAME TABLE query.

Example

Creating a table:

Query:

  1. CREATE TABLE test ENGINE = Log AS SELECT * FROM numbers(10);
  2. SELECT * FROM test;

Result:

  1. ┌─number─┐
  2. │      0 │
  3. │      1 │
  4. │      2 │
  5. │      3 │
  6. │      4 │
  7. │      5 │
  8. │      6 │
  9. │      7 │
  10. │      8 │
  11. │      9 │
  12. └────────┘

Detaching the table:

Query:

  1. DETACH TABLE test;
  2. SELECT * FROM test;

Result:

  1. Received exception from server (version 21.4.1):
  2. Code: 60. DB::Exception: Received from localhost:9000. DB::Exception: Table default.test does not exist.

See Also