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

Re: mosbench revisited

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: mosbench revisited
Date: 2011-08-03 19:11:44
Message-ID: CA+TgmobywULdmOh8Yqc8YHO9qvqD_XASeiLsXCR3mFnDmiXrTg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Aug 3, 2011 at 2:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
>
>> 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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-08-03 19:19:11
Subject: Re: Transient plans versus the SPI API
Previous:From: Bruce MomjianDate: 2011-08-03 18:52:01
Subject: Re: WAL logging volume and CREATE TABLE

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