Hi,

Usually, the solution is indeed to introduce additional components to union keys to minimize number of records fetched from the repository on expansion phase.

• Can you share execution logs, preferably with Increased unification step logging level? (To increase unification step logging level set: unify.verbose=4 parameter.)
• Also, you can check cardinality of resulting keys, by querying <REPO>_keys table, to ensure that introduction of new key factors reduced the cardinality.
• Finally, what version are you using? and how many operations are there in the Extended Unification step?​​

Appreciate your response. I did see improvement after adding a new union key.

I will check if any cardinality and identify new keys.

Version we are using Omni 3.16 and DQS 12.6.3.

I tried to look into repo_keys, When you say cardinality you mean the counts should be low when

  SELECT pk
  ,op
      ,left(lukey],3)
      ,count(*)
  FROM >omnirepo].mdbo].orepos_providerpractice_keys]
  group by  pk
  ,op
      ,left(�ukey],3)
      having count(*) >1

Is there a guide describing different fields on the repo table?

Thank you again.

Unfortunately, there is no guide. But I find it quite straightforward (take it with a grain of salt, I’m not the developer):

• pk -- primary key of the record.
• op -- operation #, in case you have multiple unify operations inside a single step.
• ukey -- unification key, all parts of the union key, combained in a signle string
• gid -- the resulting Candidate Id of the record
• center -- flag that the record was selected as a center of a group.

When I said cardinality, I meant something like that.

The first one shows how many records are in your largest candidate groups, i.e., how many records might be affected, if a new record arrives. And the second one, shows most frequent keys, it what you usually have to change, to make the candidate groups smaller.

select gid, count(*) group_rec_count
from <REPO>_keys
group by gid order by 2 desc

select ukey, count(*) key_rec_count
from <REPO>_keys
group by ukey order by 2 desc

Thank you for the detailed explanation, it really helps.

I added a union key which helped with the performance. I had to adjust the matching rules based on the new union key as it was a new field. I am currently testing.

Thanks a ton, it was helpful. Except I am trying to resolve the bundle deployment issue which always an issue. I will create a different topic for it to discuss.