On Fri, Jan 15, 2016 at 1:24 PM, Kevin Grittner <kgri...@gmail.com> wrote:
> On Fri, Jan 15, 2016 at 11:41 AM, Robert Haas <robertmh...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to