Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 166659552D4 for ; Tue, 28 Feb 2012 09:39:18 -0400 (AST) Received: from elizabeth.gransy.com ([89.187.132.199]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S2NGu-0004Ig-Tn for pgsql-performance@postgresql.org; Tue, 28 Feb 2012 13:39:17 +0000 Received: from sq.gransy.com (localhost [127.0.0.1]) by elizabeth.gransy.com (Postfix) with ESMTP id 8005B15E435D; Tue, 28 Feb 2012 14:38:57 +0100 (CET) Received: from 62.40.76.70 (proxying for unknown) (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Tue, 28 Feb 2012 14:38:57 +0100 Message-ID: <8da9b15646d973a5ee23ba49faeee8fd.squirrel@sq.gransy.com> In-Reply-To: References: <1330346798.90731.YahooMailNeo@web30808.mail.mud.yahoo.com> Date: Tue, 28 Feb 2012 14:38:57 +0100 Subject: =?utf-8?B?UmU6IFtQRVJGT1JNXSBSZTogW1BFUkZPUk1dIFJlOiDlm57lpI3vvJogW1BF?= =?utf-8?B?UkZPUk1dIFBHIGFzIGluLW1lbW9yeSBkYj8gSG93IHRvIHdhcm0gdXAgYW5k?= =?utf-8?B?IHJlLXBvcHVsYXRlIGJ1ZmZlcnM/IEhvdyB0byByZWFkIGluIGFsbCB0dXBs?= =?utf-8?B?ZXMgaW50byBtZW1vcnk/?= From: "Tomas Vondra" To: "Claudio Freire" Cc: "Stefan Keller" , "Wales Wang" , "Jeff Janes" , "pgsql-performance@postgresql.org" , "Stephen Frost" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201202/243 X-Sequence-Number: 46415 On 28 =C3=9Anor 2012, 14:08, Claudio Freire wrote: > On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller wro= te: >> >> But what I'm finally after is a solution, where records don't get >> pushed back to disk a.s.a.p. but rather got hold in memory as long as >> possible assuming that there is enough memory. > > fsync =3D off ? I don't think this is a viable idea, unless you don't care about the data= . Moreover, "fsyn=3Doff" does not mean "not writing" and writing does not m= ean "removing from shared buffers". A page written/fsynced during a checkpoin= t may stay in shared buffers. AFAIK the pages are not removed from shared buffers without a reason. So = a dirty buffer is written to a disk (because it needs to, to keep ACID) but stays in shared buffers as "clean" (unless it was written by a backend, which means there's not enough memory). Tomas