Large number of open(2) calls with bulk INSERT into empty table

From: Florian Weimer <fweimer(at)bfk(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Large number of open(2) calls with bulk INSERT into empty table
Date: 2011-11-27 15:24:34
Message-ID: 82ipm51tcd.fsf@mid.bfk.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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) = -1 ENOENT (No such file or directory)
lseek(17, 0, SEEK_END) = 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) = 8192
lseek(18, 0, SEEK_END) = 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) = 8192
lseek(18, 0, SEEK_END) = 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) = 8192
open("base/657862/16554373_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
lseek(17, 0, SEEK_END) = 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) = 8192
lseek(18, 0, SEEK_END) = 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) = 8192
open("base/657862/16554373_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
lseek(17, 0, SEEK_END) = 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) = 8192
lseek(18, 0, SEEK_END) = 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) = 8192
lseek(18, 0, SEEK_END) = 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) = 8192
open("base/657862/16554373_fsm", O_RDWR) = -1 ENOENT (No such file or directory)

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.

--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-11-27 17:12:34 small cleanup pl_exec.c
Previous Message Andrew Dunstan 2011-11-27 14:23:16 Re: pgsql: Move pg_dump memory routines into pg_dumpmem.c/h and restore com