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

Re: Postgres insert performance and storage requirement compared to Oracle

From: Divakar Singh <dpsmails(at)yahoo(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
Date: 2010-10-27 03:10:56
Message-ID: 252538.42200.qm@web65405.mail.ac4.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Dear All,
Thanks for your inputs on the insert performance part.
Any suggestion on storage requirement?
VACUUM is certainly not an option, because this is something related to 
maintenance AFTER insertion. 

I am talking about the plain storage requirement w.r. to Oracle, which I 
observed is twice of Oracle in case millions of rows are inserted.
Anybody who tried to analyze the average storage requirement of PG w.r. to 
Oracle?

 Best Regards,
Divakar




________________________________
From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>; pgsql-performance(at)postgresql(dot)org
Sent: Wed, October 27, 2010 4:46:53 AM
Subject: Re: [PERFORM] Postgres insert performance and storage requirement 
compared to Oracle

On Tue, Oct 26, 2010 at 6:50 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Oct 26, 2010 at 5:54 PM, Mladen Gogala
> <mladen(dot)gogala(at)vmsinfo(dot)com> wrote:
>> The table is created with "on commit obliterate rows" option which means
>> that there is no need to do "truncate". The "truncate" command is a heavy
>> artillery. Truncating a temporary table is like shooting ducks in a duck
>> pond, with a howitzer.
>
> This is just not true.  ON COMMIT DELETE ROWS simply arranges for a
> TRUNCATE to happen immediately before each commit.  See
> PreCommit_on_commit_actions() in tablecmds.c.

quite so.  If you are doing anything performance sensitive with 'on
commit drop', you are better off organizing a cache around
txid_current() (now(), pid for older pg versions).  Skips the writes
to the system catalogs and truncate.

merlin

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-10-27 03:48:04
Subject: Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
Previous:From: Robert HaasDate: 2010-10-27 03:05:10
Subject: Re: odd postgresql performance (excessive lseek)

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-10-27 07:53:31
Subject: Re: Simplifying replication
Previous:From: Robert HaasDate: 2010-10-27 02:03:59
Subject: Re: Simplifying replication

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