7.3.19. database_unmap

7.3.19.1. Summary

Added 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.19.2. Syntax

This command takes no parameters:

database_unmap

7.3.19.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],1]
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",
#         "lib/proc.c",
#         2929
#       ]
#     ]
#   ],
#   false
# ]

7.3.19.4. Parameters

This section describes all parameters.

7.3.19.4.1. Required parameters

There is no required parameter.

7.3.19.4.2. Optional parameters

There is no optional parameter.

7.3.19.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.