Skip site navigation (1) Skip section navigation (2)

Re: Re: Postgres insert performance and storage requirement compared to Oracle

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ivan Voras <ivoras(at)freebsd(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Re: Postgres insert performance and storage requirement compared to Oracle
Date: 2010-10-28 02:01:07
Message-ID: (view raw or whole thread)
Lists: pgsql-hackerspgsql-performance
On Wed, Oct 27, 2010 at 6:13 AM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
> On 10/26/10 17:41, Merlin Moncure wrote:
>> On Tue, Oct 26, 2010 at 11:08 AM, Leonardo Francalanci <m_lists(at)yahoo(dot)it> 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.

Gee, I wonder if it would possible for PG to automatically do an
asynchronous commit of any transaction which touches only temp tables.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-performance by date

Next:From: Francisco ReyesDate: 2010-10-28 02:30:08
Subject: Re: How does PG know if data is in memory?
Previous:From: Robert HaasDate: 2010-10-28 01:55:06
Subject: Re: BBU Cache vs. spindles

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-10-28 03:00:16
Subject: Re: Composite Types and Function Parameters
Previous:From: Jaime CasanovaDate: 2010-10-28 01:44:21
Subject: Re: An unfortunate logging behavior when (mis)configuring recovery.conf

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group