Skip site navigation (1) Skip section navigation (2)

Re: mosbench revisited

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: mosbench revisited
Date: 2011-08-03 18:49:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Martijn van Oosterhout <kleptog(at)svana(dot)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.


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.

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?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-08-03 18:52:01
Subject: Re: WAL logging volume and CREATE TABLE
Previous:From: Dimitri FontaineDate: 2011-08-03 18:41:56
Subject: Re: Transient plans versus the SPI API

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group