Re: vacuum after truncate

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-performance(at)postgresql(dot)org>
Subject: Re: vacuum after truncate
Date: 2017-12-05 14:40:54
Message-ID: 1512484854.2706.3.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Mariel Cherkassky wrote:
> Hi,
> I have a big function that includes many truncates on different tables.
> In the documentation is is written that truncates creates a new file
> and resign the old filenode to the new filenode and the old file
> (old data of the table) is deleted in commit.
>
> In order to execute my function I run psql -d 'aa' -U 'bb' -C "select function()";
>
> I have a few questions about it ?
>
> 1.When I start the function, it means that the whole function is one big transaction right ?

Right.

> 2..Because the truncates I preform are part of a transaction it means that only at the end
> of the transaction that space will be freed ? Which mean only when the function is finished?

Exactly. The old file has to be retained, because there could be a ROLLBACK.

> 3..Does running vacuum at the end of the function on the tables that were truncated and
> then populated with data will have any impact or is it better just to analyze them ?

For up-to-date statistics, ANALYZE is enough.
If you want to set hint bits so that the first reader doesn't have to do it,
VACUUM will help. But that is not necessary.

Yours,
Laurenz Albe

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Rodrigo Rosenfeld Rosas 2017-12-05 16:21:38 Extremely slow DELETE with cascade foreign keys
Previous Message Mariel Cherkassky 2017-12-05 14:03:11 vacuum after truncate