Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 7BA9F1E64F41 for ; Sun, 27 Nov 2011 11:24:57 -0400 (AST) Received: from mx01.bfk.de ([193.227.124.2]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RUgb4-0000HS-T4 for pgsql-hackers@postgresql.org; Sun, 27 Nov 2011 15:24:57 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RUgao-0004Nj-VS for pgsql-hackers@postgresql.org; Sun, 27 Nov 2011 15:24:34 +0000 Received: by bfk.de with local id 1RUgao-0001Bj-Ra for pgsql-hackers@postgresql.org; Sun, 27 Nov 2011 15:24:34 +0000 From: Florian Weimer To: pgsql-hackers@postgresql.org Subject: Large number of open(2) calls with bulk INSERT into empty table Date: Sun, 27 Nov 2011 15:24:34 +0000 Message-ID: <82ipm51tcd.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -3.1 (---) X-Archive-Number: 201111/1536 X-Sequence-Number: 199021 I noticed that a bulk INSERT into an empty table (which has been TRUNCATEd in the same transaction, for good measure) results in a curious number of open(2) calls for the FSM resource fork: open("base/657862/16554373_fsm", O_RDWR) =3D -1 ENOENT (No such file or dir= ectory) lseek(17, 0, SEEK_END) =3D 407584768 write(17, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 lseek(18, 0, SEEK_END) =3D 333119488 write(18, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 lseek(18, 0, SEEK_END) =3D 333127680 write(18, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 open("base/657862/16554373_fsm", O_RDWR) =3D -1 ENOENT (No such file or dir= ectory) lseek(17, 0, SEEK_END) =3D 407592960 write(17, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 lseek(18, 0, SEEK_END) =3D 333135872 write(18, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 open("base/657862/16554373_fsm", O_RDWR) =3D -1 ENOENT (No such file or dir= ectory) lseek(17, 0, SEEK_END) =3D 407601152 write(17, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 lseek(18, 0, SEEK_END) =3D 333144064 write(18, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 lseek(18, 0, SEEK_END) =3D 333152256 write(18, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= "..., 8192) =3D 8192 open("base/657862/16554373_fsm", O_RDWR) =3D -1 ENOENT (No such file or dir= ectory) I'm not sure if this result in a significant performance hit on Linux (because the dentry cache covers negative lookups, too), but I suspect that it could be an issue with other systems. This happens with PostgreSQL 9.1.0. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99