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