From: Divakar Singh <dpsmails@yahoo.com>
To: Merlin Moncure <mmoncure@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
Date: Tue, 26 Oct 2010 20:10:56 -0700 (PDT)
Message-ID: <252538.42200.qm@web65405.mail.ac4.yahoo.com> (raw)
In-Reply-To: <AANLkTi=-fK6ODDNJPntq3OeUJQzKtHbsmkdDM851waOG@mail.gmail.com>
References: <402913.53404.qm@web65405.mail.ac4.yahoo.com>
<AANLkTi=0iZDF7EHebukEJ+jxFN8giCy3iXxYuSe_mLUY@mail.gmail.com>
<AANLkTi=cy67frLbx+YH_uUk5vqPsxt8u-Q_cpU74pYMq@mail.gmail.com>
<208728.42197.qm@web65409.mail.ac4.yahoo.com>
<AANLkTikeYj52q1v1RcwCYR=9Kv5mxJmh+Q+KvXcmibYK@mail.gmail.com>
<770715.39613.qm@web29003.mail.ird.yahoo.com>
<AANLkTinaW3ZtGJbzgAARG0WfAOJxSPAbdVAZa6X_2dh+@mail.gmail.com>
<4CC741FF.8050709@vmsinfo.com>
<AANLkTinntqfT1b9xaRfGGqVwwsGhyA7=JhLsuQ10Xzyy@mail.gmail.com>
<4CC74E31.6060307@vmsinfo.com>
<AANLkTimf9Nj8A+Spiu9q3suvZ+h71CHXRFTXFo_5aBYj@mail.gmail.com>
<AANLkTi=-fK6ODDNJPntq3OeUJQzKtHbsmkdDM851waOG@mail.gmail.com>
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@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>; pgsql-performance@postgresql.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@gmail.com> wrote:
> On Tue, Oct 26, 2010 at 5:54 PM, Mladen Gogala
> <mladen.gogala@vmsinfo.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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: dpsmails@yahoo.com, mmoncure@gmail.com, robertmhaas@gmail.com, mladen.gogala@vmsinfo.com
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
In-Reply-To: <252538.42200.qm@web65405.mail.ac4.yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox