On Wed, Aug 3, 2011 at 2:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Martijn van Oosterhout <klep...@svana.org> writes: >> On Wed, Aug 03, 2011 at 02:21:25PM -0400, Robert Haas wrote: >>> It would be nice if the Linux guys would fix this problem for us, but >>> I'm not sure whether they will. For those who may be curious, the >>> problem is in generic_file_llseek() in fs/read-write.c. On a platform >>> with 8-byte atomic reads, it seems like it ought to be very possible >>> to read inode->i_size without taking a spinlock. > >> Interesting. There's this thread from 2003 suggesting the use of pread >> instead, it was rejected on the argument that lseek is cheap so not a >> problem. > >> http://archives.postgresql.org/pgsql-patches/2003-02/msg00197.php > > That seems rather unrelated. The point here is our use of lseek to find > out the current file size --- or at least, I would hope they're not > trying to read the inode's file size in a SEEK_CUR call.
Correct. > The reason "-M prepared" helps is presumably that it eliminates most of > the RelationGetNumberOfBlocks calls the planner does to check current > table size. While we could certainly consider using a cheaper (possibly > more stale) value there, it's a bit astonishing to think that that's the > main cost in a parse/plan/execute cycle. Perhaps there are more hotspot > calls than that one? Nope. On a straight pgbench -S test, you get four system calls per query: recvfrom(), lseek(), lseek(), sendto(). Adding -M prepared eliminates the two lseeks. -- 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
