# 7.3.18. `database_unmap`

## 7.3.18.1. Summary

New in version 5.0.7.

`database_unmap` unmaps already mapped tables and columns in the database. “Map” means that loading from disk to memory. “Unmap” means that releasing mapped memory.

Note

Normally, you don’t need to use `database_unmap` because OS manages memory cleverly. If remained system memory is reduced, OS moves memory used by Groonga to disk until Groonga needs the memory. OS moves unused memory preferentially.

Caution

You can use this command only when thread_limit returns `1`. It means that this command doesn’t work with multithreading.

## 7.3.18.2. Syntax

This command takes no parameters:

    database_unmap

## 7.3.18.3. Usage

You can unmap database after you change the max number of threads to `1`:

Execution example:

    thread_limit --max 1
    # [[0, 1337566253.89858, 0.000355720520019531], 2]
    database_unmap
    # [[0, 1337566253.89858, 0.000355720520019531], true]

If the max number of threads is larger than `1`, `database_unmap` fails:

Execution example:

    thread_limit --max 2
    # [[0, 1337566253.89858, 0.000355720520019531], 1]
    database_unmap
    # [
    #   [
    #     -2,
    #     1337566253.89858,
    #     0.000355720520019531,
    #     "[database_unmap] the max number of threads must be 1: <2>",
    #     [
    #       [
    #         "proc_database_unmap",
    #         "proc.c",
    #         3705
    #       ]
    #     ]
    #   ],
    #   false
    # ]

## 7.3.18.4. Parameters

This section describes all parameters.

### 7.3.18.4.1. Required parameters

There is no required parameter.

### 7.3.18.4.2. Optional parameters

There is no optional parameter.

## 7.3.18.5. Return value

The command returns `true` as body on success such as:

    [HEADER, true]

If the command fails, error details are in `HEADER`.

See Output format for `HEADER`.

previous

7.3.17. `config_set`

next

7.3.19. `define_selector`