Re: Truncating/vacuuming relations on full tablespaces

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Truncating/vacuuming relations on full tablespaces
Date: 2015-11-23 16:50:17
Message-ID: 565343C9.8060305@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/4/15 7:04 AM, Thom Brown wrote:
> But shouldn't we not be creating FSM or VM files when truncating?

Maybe, but even then you still need to create a bunch of new files (at
least one for the table and one for each index), and AFAIK the first
page in each file will be properly initialized, which means each file
will be at least BLKSZ.

> ISTM that the vacuum case is one we'd really want to avoid, though, as
> it's trickier to work around the problem.

What might make sense is a special 'free up space NOW' mode that focuses
only on attempting to truncate the relation, because if you can't
actually shrink the heap you're not going to make any progress.

But since none of this will help at all in the default case where WAL is
on the same filesystem as the data, I don't know that it's worth it.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-11-23 16:59:04 Re: custom function for converting human readable sizes to bytes
Previous Message Jim Nasby 2015-11-23 16:42:18 Re: [PROPOSAL] Inputs on forcing VACUUM VERBOSE to write timestamp