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@xxxxxxxxx>
To: Robert Haas <robertmhaas@xxxxxxxxx>
Cc: Mladen Gogala <mladen.gogala@xxxxxxxxxxx>; pgsql-performance@xxxxxxxxxxxxxx
Sent: Wed, October 27, 2010 4:46:53 AM
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
On Tue, Oct 26, 2010 at 6:50 PM, Robert Haas <robertmhaas@xxxxxxxxx> wrote:
> On Tue, Oct 26, 2010 at 5:54 PM, Mladen Gogala
> <mladen.gogala@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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?
Divakar
From: Merlin Moncure <mmoncure@xxxxxxxxx>
To: Robert Haas <robertmhaas@xxxxxxxxx>
Cc: Mladen Gogala <mladen.gogala@xxxxxxxxxxx>; pgsql-performance@xxxxxxxxxxxxxx
Sent: Wed, October 27, 2010 4:46:53 AM
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
On Tue, Oct 26, 2010 at 6:50 PM, Robert Haas <robertmhaas@xxxxxxxxx> wrote:
> On Tue, Oct 26, 2010 at 5:54 PM, Mladen Gogala
> <mladen.gogala@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
