Hi,
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Rudi
Starcevic) transmitted:
A minute for your thoughts and/or suggestions would be great.
Heh heh
Could you give a more concrete example? E.g. - the DDL for the
table(s), most particularly.
Thanks, I didn't add the
-Original Message-
From: Rudi Starcevic [mailto:[EMAIL PROTECTED]
Sent: Tue 8/10/2004 8:33 PM
To: [EMAIL PROTECTED]
Cc:
Subject:Re: [PERFORM] Bulk Insert and Index use
Hi Jim,
Thanks for your time.
> If the bulk load has the possibility of duplicating data
Yes, each row w
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Rudi
Starcevic) transmitted:
> A minute for your thoughts and/or suggestions would be great.
Could you give a more concrete example? E.g. - the DDL for the
table(s), most particularly.
At first guess, I think you're worryi
Hi Jim,
Thanks for your time.
> If the bulk load has the possibility of duplicating data
Yes, each row will require either:
a) One SELECT + One INSERT
or
b) One SELECT + One UPDATE
I did think of using more than one table, ie. temp table.
As each month worth of data is added I expect to see
a chang
Usualy any bulk load is faster with indexes dropped and the rebuilt ... failing that
(like you really need the indexes while loading, say into a "hot" table) be sure to
wrap all the SQL into one transaction (BEGIN;...COMMIT;) ... if any data failes it all
fails, which is usually easier to deal
If the bulk load has the possibility of duplicating data, then you need
to change methods. Try bulk loading into a temp table, index it like
the original, eliminate the dups and merge the tables.
It is also possible to do an insert from the temp table into the final
table like:
insert into or
