On Fri, Jan 15, 2016 at 1:24 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Fri, Jan 15, 2016 at 11:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Anybody else want to weigh in with thoughts on any of this?
>
> Leaving aside VACUUM issues for a moment, what problems to you see
> with an empty table that has no visibility map or free space map
> fork? In other words, for the TRUNCATE case we could either skip
> these if there is an error, or not even try to build them at all.
> Either seems better than the status quo.
The status quo *is* that we don't try to build them at all.
rhaas=# create table foo (a int, b int);
CREATE TABLE
rhaas=# insert into foo values (1,1);
INSERT 0 1
rhaas=# vacuum analyze foo;
VACUUM
rhaas=# select relfilenode from pg_class where relname = 'foo';relfilenode
------------- 16385
(1 row)
In another window:
-rw------- 1 rhaas staff 8192 Jan 15 13:45 16385
-rw------- 1 rhaas staff 24576 Jan 15 13:45 16385_fsm
-rw------- 1 rhaas staff 8192 Jan 15 13:45 16385_vm
Back to the first window:
rhaas=# truncate foo;
TRUNCATE TABLE
rhaas=# select relfilenode from pg_class where relname = 'foo';relfilenode
------------- 16388
(1 row)
Back to the second window:
[rhaas 16384]$ ls -l 16388*
-rw------- 1 rhaas staff 0 Jan 15 13:46 16388
There's no full disk involved here or anything. Just a plain old TRUNCATE.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
