Hi,

There's several factors that come into play. On the database side, if you specify only a few properties, fewer IH "dimension" tables may need to be joined, which might actually be quite a bit more efficient. There will be more data sent over the network but I would be surprised if that is large compared to whole execution cycle. On the PRPC side, fewer properties help reduce the memory footprint, as well as reduce the amount of data that needs to be copied/joined etc (things can get fairly complex when you do multiple IH imports in a single strategy call).

You can see the IH queries if you turn on DB tracing.

So I would not expect massive performance gains but when your application is heavy on IH I would certainly consider doing this. At the end of the day, all CPU cycles count. 

BTW note that the proposition import shape also has an option to include interaction history (which saves quite some configuration and is more efficient). 

-Otto

Thanks.   Also if we had a condition directly on the IH component, such as .pyOutcome = Accept , would that be built into the sql or would the condition be filter after the sql and results are brought into Pega?

Hi Bellerophon,

The conditions you specify in the IH import shape (Fetch when the conditions below are met) will make it into the generated SQL query, e.g. there would be something like this folded into the WHERE clauses:

...
AND ((("OUTCOMETABLE".pyOutcome = '"Accept"')))
...

At least in simple cases. Not 100% sure this is still true in the presence of multiple IH imports in a strategy - as I mentioned, things do get complex and a mix of SQL and Java postprocessing will be used.

-Otto