> We have a very poorly performing MERGE statement (an hour or more on
> tables of ~10000 and ~100000). This may require building temporary
[quoted text clipped - 21 lines]
> on nullid.angus_in(tattoo, sex, birth_date,
> assoc, sire_regnum, dam_regnum)
One of the most important criteria for MEREG to perform is that the
source produces provably (by DB2 that is) DISTINCT rows w.r.t. the ON
clause. If that is not the case MERGE requires that DB2 detects
duplicate updates and raises a runtime error. This is costly.
MERGE shines when the on clause is on a key.
In your case it's inetersting that you apply t2.regnum IS NULL in teh
MATCHED clause. Typically predicates there are used to distinguish
between UPDATE and DELETE branches.
Cheers
Serge

Signature
Serge Rielau
DB2 Solutions Development
DB2 UDB for Linux, Unix, Windows
IBM Toronto Lab
Bob Stearns - 12 Jan 2006 21:47 GMT
>> We have a very poorly performing MERGE statement (an hour or more on
>> tables of ~10000 and ~100000). This may require building temporary
[quoted text clipped - 33 lines]
> Cheers
> Serge
Thanks for the quick reply. You missed (or maybe thought I knew what was
doing:-) the not so obvious error in the last JOIN: ts.bhid should have
been td.bhid; the syntax scanner can not find logical errors. My only
excuse is that it was not written by me but a colleague.
Serge Rielau - 13 Jan 2006 02:12 GMT
>>> We have a very poorly performing MERGE statement (an hour or more on
>>> tables of ~10000 and ~100000). This may require building temporary
[quoted text clipped - 38 lines]
> been td.bhid; the syntax scanner can not find logical errors. My only
> excuse is that it was not written by me but a colleague.
Ah yes.. a bad on clause may do you in in no time but for long time

Signature
Serge Rielau
DB2 Solutions Development
DB2 UDB for Linux, Unix, Windows
IBM Toronto Lab