Re: question on error during COPY FROM

From: Francisco Olarte <folarte(at)peoplecall(dot)com>
To: Ilya Kazakevich <Ilya(dot)Kazakevich(at)jetbrains(dot)com>
Cc: Jerome Wagner <jerome(dot)wagner(at)laposte(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: question on error during COPY FROM
Date: 2016-08-23 13:55:47
Message-ID: CA+bJJbx=QLg-MUoxdHSXiWtbHpxMw-XqL60qDKh8BG-tpopA_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Aug 23, 2016 at 2:32 PM, Ilya Kazakevich
<Ilya(dot)Kazakevich(at)jetbrains(dot)com> wrote:
>>does that mean that I should always execute a VACUUM to recover the
>>wasted space when an error is triggered or will the auto-vacuum mechanism
>>do the job by itself ?
> If you have autovacuum enabled it will clean up tablespace. However, space will not be returned to filesystem but will be reused by database.
> You may run VACUUM FULL manually to return it to filesystem.

A normal vacuum may also return some space, specially after a big bulk
load, see second paragraph of 23.1.2 the URL you posted:
> https://www.postgresql.org/docs/9.1/static/routine-vacuuming.html

Where it says "However, it will not return the space to the operating
system, except in the special case where one or more pages at the end
of a table become entirely free and an exclusive table lock can be
easily obtained.". A big aborted bulk load may just fit the case, as
it may put a lot of tuples at new pages at the end and be executed in
a low-load period where the lock is easier to acquire.

Francisco Olarte.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2016-08-23 14:04:50 Re: Why insertion throughput can be reduced with an increase of batch size?
Previous Message Francisco Olarte 2016-08-23 13:44:54 Re: Sequential vs. random values - number of pages in B-tree