To: Ivan Voras <ivoras@freebsd.org>
cc: pgsql-performance@postgresql.org
Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance 
In-reply-to: <i8itbn$kre$1@dough.gmane.org> 
References: <AANLkTimW2UgVPGw6MRUBj9HabvwmsmkZasL3hKv-nUJ2@mail.gmail.com>
	<20101004175545.GA2690@csail.mit.edu>
	<4CAA21C7.1030701@agliodbs.com> <i8itbn$kre$1@dough.gmane.org>
Comments: In-reply-to Ivan Voras <ivoras@freebsd.org>
	message dated "Thu, 07 Oct 2010 00:31:19 +0200"
Date: Wed, 06 Oct 2010 21:25:07 -0400
Message-ID: <16636.1286414707@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ivan Voras <ivoras@freebsd.org> writes:
> On 10/04/10 20:49, Josh Berkus wrote:
>>> The other major bottleneck they ran into was a kernel one: reading from
>>> the heap file requires a couple lseek operations, and Linux acquires a
>>> mutex on the inode to do that.

> Hmmm... lseek? As in "lseek() then read() or write()" idiom? It AFAIK
> cannot be fixed since you're modifying the global "strean position"
> variable and something has got to lock that.

Um, there is no "global stream position" associated with an inode.
A file position is associated with an open-file descriptor.

If Josh quoted the problem correctly, the issue is that the kernel is
locking a file's inode (which may be referenced by quite a lot of file
descriptors) in order to change the state of one file descriptor.
It sure sounds like a possible source of contention to me.

			regards, tom lane