# Pega Report Definition Performance when Joining Embedded Lists

**URL:** <https://forums.pega.com/t/pega-report-definition-performance-when-joining-embedded-lists/11629>\
**Category:** General\
**Tags:** performance, pega-infinity, senior-system-architect, case-management\
**Created:** [April 20, 2026, 3:41pm UTC](https://forums.pega.com/t/pega-report-definition-performance-when-joining-embedded-lists/11629 "2026-04-20T15:41:01Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![SamZ17526999](https://avatars.discourse-cdn.com/v4/letter/s/898d66/32.png) [@SamZ17526999](https://forums.pega.com/u/SamZ17526999)\
**Post date:** [April 20, 2026, 3:41pm UTC](https://forums.pega.com/t/pega-report-definition-performance-when-joining-embedded-lists/11629/1 "2026-04-20T15:41:01Z")

</div>

I have ~3.5M work objects in Pega, each containing a variable‑length embedded Page List. I need to apply search/filter criteria that match the corresponding fields in any item of the embedded list across all work objects.

I currently have a Report Definition on an Index‑ class built on the work object. I am using a class join between the Index‑ class (via `pxInsIndexedKey`) and the embedded list items (via `pxInsIndexedKey`) to apply my search criteria. I’m concerned that this approach will cause performance issues when we are searching across so many work objects and was wondering if:

1. My approach would meaningfully improve performance or if it is still likely to become a bottleneck.

2. And whether there is a better or more scalable design pattern for handling this type of requirement in Pega.

Many thanks for your guidance on this issue.

---

<div class="post-metadata">

**Author:** ![PoojaPalla](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/poojapalla/32/12434_2.png) [@PoojaPalla](https://forums.pega.com/u/PoojaPalla)\
**Post date:** [April 21, 2026, 2:10am UTC](https://forums.pega.com/t/pega-report-definition-performance-when-joining-embedded-lists/11629/2 "2026-04-21T02:10:03Z")

</div>

From my understanding, using an **Index- class with joins on `pxInsIndexedKey`** is a valid approach, but at ~3.5M records it can still become a **performance bottleneck** , especially with large/variable page lists and frequent queries.

**What you can try:**

- Query **directly on the Index class** instead of joining with Work

- Ensure proper **DB indexes** on frequently searched fields

- Use **Declare Index** to flatten data efficiently

---

<div class="post-metadata">

**Author:** ![RameshSangili](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/rameshsangili/32/23377_2.png) [@RameshSangili](https://forums.pega.com/u/RameshSangili)\
**Post date:** [April 22, 2026, 1:56am UTC](https://forums.pega.com/t/pega-report-definition-performance-when-joining-embedded-lists/11629/3 "2026-04-22T01:56:58Z")

</div>

> [@SamZ17526999](#):
>
> have ~3.5M work objects in Pega, each containing a variable‑length embedded Page List. I need to apply search/filter criteria that match the corresponding fields in any item of the embedded list across all work objects.
> 
> I currently have a Report Definition on an Index‑ class built on the work object. I am using a class join between the Index‑ class (via `pxInsIndexedKey`) and the embedded list items (via `pxInsIndexedKey`) to apply my search criteria. I’m concerned that this approach will cause performance issues when we are searching across so many work objects and was wondering if:
> 
> 1. My approach would meaningfully improve performance or if it is still likely to become a bottleneck.
> 2. And whether there is a better or more scalable design pattern for handling this type of requirement in Pega.
> 
> Many thanks for your guidance on this issue.

Run the explain query to identify the missing indexes and cost factor. If you’re on Pega Cloud, work with Pega cloud team to add the necessary indexes or work with your DBAs to add the necessary indexes and fine tune the query based on DBA recommendations.