Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id C031B3E3C9A for ; Sun, 4 Dec 2011 08:28:22 -0400 (AST) Received: from 7.mo4.mail-out.ovh.net ([178.33.253.54] helo=mo4.mail-out.ovh.net) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RXBB7-0007Nt-FZ for pgsql-performance@postgresql.org; Sun, 04 Dec 2011 12:28:22 +0000 Received: from mail177.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id DD9F3106465F for ; Sun, 4 Dec 2011 13:28:11 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 4 Dec 2011 14:28:07 +0200 Received: from civ69-1-88-168-96-119.fbx.proxad.net (HELO apollo13) (lists%peufeu.com@88.168.96.119) by ns0.ovh.net with SMTP; 4 Dec 2011 14:28:05 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "'Kevin Grittner'" , "'Richard Huxton'" , "'Sergey Konoplev'" , "Anibal David Acosta" Cc: pgsql-performance@postgresql.org, "'Stephen Frost'" X-Ovh-Mailout: 178.32.228.4 (mo4.mail-out.ovh.net) Subject: Re: unlogged tables References: <005501cca0ad$b9478440$2bd68cc0$@devshock.com> <20111111201822.GN24234@tamriel.snowman.net> <4EC0D827.8090601@archonet.com> <4EC0EAD6.9010302@archonet.com> <00ea01cca2ef$abcf3a30$036dae90$@devshock.com> <4EC0FAE80200002500042E6C@gw.wicourts.gov> <00ff01cca2f4$3cb86860$b6293920$@devshock.com> Date: Sun, 04 Dec 2011 13:28:03 +0100 MIME-Version: 1.0 From: "Pierre C" Message-ID: In-Reply-To: <00ff01cca2f4$3cb86860$b6293920$@devshock.com> User-Agent: Opera Mail/11.52 (Linux) X-Ovh-Tracer-Id: 7445576084665403061 X-Ovh-Remote: 88.168.96.119 (civ69-1-88-168-96-119.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeefjedruddvucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptgfvufhfffgggffhkfgjfgesthekredttderjeenucfhrhhomhepfdfrihgvrhhrvgcuvedfuceolhhishhtshesphgvuhhfvghurdgtohhmqeenucffohhmrghinhepne X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeefjedruddvucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptgfvufhfffgggffhkfgjfgesthekredttderjeenucfhrhhomhepfdfrihgvrhhrvgcuvedfuceolhhishhtshesphgvuhhfvghurdgtohhmqeenucffohhmrghinhepne Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201112/25 X-Sequence-Number: 45825 > My table is a statistics counters table, so I can live with a partial =20 > data > loss, but not with a full data loss because many counters are weekly an= d > monthly. > > Unlogged table can increase speed, this table has about 1.6 millions of > update per hour, but unlogged with a chance of loss all information on = a > crash are not a good idea for this. You could use an unlogged table for hourly updates, and periodically, =20 accumulate those counters to a (logged) daily/weekly table... The hourly table could be rebuilt by examining only 1 hour's worth of =20 data, so it isn't too much of a problem if it's lost. The other tables =20 would get much less updates.