Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 12AB69D7DA2 for ; Fri, 2 Mar 2012 20:30:36 -0400 (AST) Received: from [2001:1528:137::f1] (helo=mail.gransy.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S3crp-0006oV-PP for pgsql-performance@postgresql.org; Sat, 03 Mar 2012 00:30:35 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id EB90D4A209C; Sat, 3 Mar 2012 01:30:18 +0100 (CET) Received: from mail.gransy.com ([82.208.29.194]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id OHBkvcWeMZ3v; Sat, 3 Mar 2012 01:30:18 +0100 (CET) Received: by mail.gransy.com (Postfix, from userid 5000) id D44A74A20A2; Sat, 3 Mar 2012 01:30:18 +0100 (CET) Received: from [192.168.1.237] (ip-78-45-133-255.net.upcbroadband.cz [78.45.133.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id A959F4A207D; Sat, 3 Mar 2012 01:30:18 +0100 (CET) Message-ID: <4F51661A.4090903@fuzzy.cz> Date: Sat, 03 Mar 2012 01:30:18 +0100 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Claudio Freire CC: "pgsql-performance@postgresql.org" Subject: =?UTF-8?B?UmU6IFtQRVJGT1JNXSBSZTogW1BFUkZPUk1dIFJlOiBbUEVSRk9STV0=?= =?UTF-8?B?IFJlOiBbUEVSRk9STV0gUmU6IOWbnuWkje+8miBbUEVSRk9STV0gUEcgYXMgaW4=?= =?UTF-8?B?LW1lbW9yeSBkYj8gSG93IHRvIHdhcm0gdXAgYW5kIHJlLXBvcHVsYXRlIGJ1ZmY=?= =?UTF-8?B?ZXJzPyBIb3cgdG8gcmVhZCBpbiBhbGwgdHVwbGVzIGludG8gbWVtb3J5Pw==?= References: <1330346798.90731.YahooMailNeo@web30808.mail.mud.yahoo.com> <8da9b15646d973a5ee23ba49faeee8fd.squirrel@sq.gransy.com> <347477cf700da0b19ad62b50cae5ae1c.squirrel@sq.gransy.com> <7993f32e79b113a0ca3de4d9e500d106.squirrel@sq.gransy.com> <4F501EC0.6070801@fuzzy.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:1528:137::f1 (failed) X-Pg-Spam-Score: -1.1 (-) X-Archive-Number: 201203/43 X-Sequence-Number: 46493 On 2.3.2012 03:05, Claudio Freire wrote: > On Thu, Mar 1, 2012 at 10:13 PM, Tomas Vondra wrote: >> >> Maybe. I still am not sure how fsync=off affects the eviction in your >> opinion. I think it does not (or just very remotely) and you were saying >> the opposite. IMHO the eviction of (dirty) buffers is either very fast >> or slow, no matter what the fsync setting is. > > I was thinking page cleanup, but if you're confident it doesn't happen > on a read-only database, I'd have to agree on all your other points. > > I have seen a small amount of writes on a read-only devel DB I work > with, though. Usually in the order of 100kb/s writes per 10mb/s reads > - I attributed that to page cleanup. In that case, it can add some > wait time to fsync, even though it's really a slow volume of writes. > If you're right, I'm thinking, it may be some other thing... atime > updates maybe, I'd have to check the filesystem configuration I guess. I'd guess those writes were caused by hint bits (~ page cleanup, but that's a one-time thing and should be fixed by VACUUM FREEZE right after the load). Or maybe it was related to runtime stats (i.e. pgstat). T.