From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Vince Negri <vnegri(at)asl-electronics(dot)co(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: TRUNCATE - timing of the return of disk space - caused by long-lived client? |
Date: | 2007-10-26 12:05:26 |
Message-ID: | 20071026120526.GA5968@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Vince Negri wrote:
> So I tried TRUNCATE on the table. It appeared to work - in that the
> row count dropped to zero and the connected client was not disrupted,
> and "du" on the postgres data directory showed a fall.
>
> But the available disk space (reported by "df") did not fall.
I think you shouldn't worry about it. The file will eventually be
closed (maybe after a couple of checkpoints) and the space returned to
the filesystem.
FYI what TRUNCATE does is create a new, separate file for the table and
index storages. The old one can still be open for a while, but it
should get detached not long after the transaction commits.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-10-26 12:07:02 | Re: 8.2.3: Server crashes on Windows using Eclipse/Junit |
Previous Message | Martijn van Oosterhout | 2007-10-26 11:56:20 | Re: INDEX and JOINs |