Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id DB8161337B59 for ; Wed, 27 Oct 2010 07:13:33 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 86208-08 for ; Wed, 27 Oct 2010 10:13:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id 4EAFA133798F for ; Wed, 27 Oct 2010 07:13:19 -0300 (ADT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PB30P-0001Up-BX for pgsql-performance@postgresql.org; Wed, 27 Oct 2010 12:13:17 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2010 12:13:17 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2010 12:13:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: Postgres insert performance and storage requirement compared to Oracle Date: Wed, 27 Oct 2010 12:13:10 +0200 Lines: 20 Message-ID: References: <402913.53404.qm@web65405.mail.ac4.yahoo.com> <208728.42197.qm@web65409.mail.ac4.yahoo.com> <770715.39613.qm@web29003.mail.ird.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20101018 Thunderbird/3.0.8 In-Reply-To: X-Enigmail-Version: 1.0.1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/464 X-Sequence-Number: 40882 On 10/26/10 17:41, Merlin Moncure wrote: > On Tue, Oct 26, 2010 at 11:08 AM, Leonardo Francalanci wrote: >>> temp tables are not wal logged or >>> synced. Periodically they can be flushed to a permanent table. >> >> >> What do you mean with "Periodically they can be flushed to >> a permanent table"? Just doing >> >> insert into tabb select * from temptable >> > > yup, that's exactly what I mean -- this will give you more uniform In effect, when so much data is in temporary storage, a better option would be to simply configure "synchronous_commit = off" (better in the sense that the application would not need to be changed). The effects are almost the same - in both cases transactions might be lost but the database will survive.