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 <[email protected]> To: Robert Haas <[email protected]> Cc: Mladen Gogala <[email protected]>; [email protected] 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 <[email protected]> wrote: > On Tue, Oct 26, 2010 at 5:54 PM, Mladen Gogala > <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
