9.3.6. /db/_compact

POST /{db}/_compact

Request compaction of the specified database. Compaction compresses the disk database file by performing the following operations:

  • Writes a new, optimised, version of the database file, removing any unused sections from the new version during write. Because a new file is temporarily created for this purpose, you may require up to twice the current storage space of the specified database in order for the compaction routine to complete.
  • Removes old revisions of documents from the database, up to the per-database limit specified by the _revs_limit database parameter.

Compaction can only be requested on an individual database; you cannot compact all the databases for a CouchDB instance. The compaction process runs as a background process.

You can determine if the compaction process is operating on a database by obtaining the database meta information, the compact_running value of the returned database structure will be set to true. See GET /{db}.

You can also obtain a list of running processes to determine whether compaction is currently running. See /_active_tasks.

Parameters:
  • db – Database name
Request Headers:
 
Response Headers:
 
  • Content-Type
    • application/json
    • text/plain; charset=utf-8
Response JSON Object:
 
  • ok (boolean) – Operation status
Status Codes:

Request:

POST /db/_compact HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: localhost:5984

Response:

HTTP/1.1 202 Accepted
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: application/json
Date: Mon, 12 Aug 2013 09:27:43 GMT
Server: CouchDB (Erlang/OTP)

{
    "ok": true
}

9.3.7. /db/_compact/design-doc

POST /{db}/_compact/{ddoc}

Compacts the view indexes associated with the specified design document. If may be that compacting a large view can return more storage than compacting the actual db. Thus, you can use this in place of the full database compaction if you know a specific set of view indexes have been affected by a recent database change.

Parameters:
  • db – Database name
  • ddoc – Design document name
Request Headers:
 
Response Headers:
 
  • Content-Type
    • application/json
    • text/plain; charset=utf-8
Response JSON Object:
 
  • ok (boolean) – Operation status
Status Codes:

Request:

POST /db/_compact/posts HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: localhost:5984

Response:

HTTP/1.1 202 Accepted
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: application/json
Date: Mon, 12 Aug 2013 09:36:44 GMT
Server: CouchDB (Erlang/OTP)

{
    "ok": true
}

.. note::

  View indexes are stored in a separate ``.couch`` file based on
  a hash of the design document's relevant functions, in a sub directory
  of where the main ``.couch`` database files are located.

9.3.8. /db/_ensure_full_commit

POST /{db}/_ensure_full_commit

Commits any recent changes to the specified database to disk. You should call this if you want to ensure that recent changes have been flushed. This function is likely not required, assuming you have the recommended configuration setting of delayed_commits=false, which requires CouchDB to ensure changes are written to disk before a 200 or similar result is returned.

Parameters:
  • db – Database name
Request Headers:
 
Response Headers:
 
  • Content-Type
    • application/json
    • text/plain; charset=utf-8
Response JSON Object:
 
  • instance_start_time (string) – Timestamp of when the database was opened, expressed in microseconds since the epoch.
  • ok (boolean) – Operation status
Status Codes:

Request:

POST /db/_ensure_full_commit HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: localhost:5984

Response:

HTTP/1.1 201 Created
Cache-Control: must-revalidate
Content-Length: 53
Content-Type: application/json
Date: Mon, 12 Aug 2013 10:22:19 GMT
Server: CouchDB (Erlang/OTP)

{
    "instance_start_time": "1376269047459338",
    "ok": true
}

9.3.9. /db/_view_cleanup

POST /{db}/_view_cleanup

Removes view index files that are no longer required by CouchDB as a result of changed views within design documents. As the view filename is based on a hash of the view functions, over time old views will remain, consuming storage. This call cleans up the cached view output on disk for a given view.

Parameters:
  • db – Database name
Request Headers:
 
Response Headers:
 
  • Content-Type
    • application/json
    • text/plain; charset=utf-8
Response JSON Object:
 
  • ok (boolean) – Operation status
Status Codes:

Request:

POST /db/_view_cleanup HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: localhost:5984

Response:

HTTP/1.1 202 Accepted
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: application/json
Date: Mon, 12 Aug 2013 09:27:43 GMT
Server: CouchDB (Erlang/OTP)

{
    "ok": true
}