Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Score big with last-minute savings on the final tickets to FabCon Vienna. Secure your discount

Reply
alexei7
Continued Contributor
Continued Contributor

Poorly performing DAX help

Hi,

 

I've been getting the "Resources Exceeded" messages on one of the visualisations in a report i've published and hoping someone can help.

 

The DAX is as follows:

 

Fundraising Pages PYTD = CALCULATE(TOTALYTD(COUNTROWS('fundraising_page'),'Fundraising Page Date Dimension'[CALENDAR_DATE]),'page'[page_status]<>2,SAMEPERIODLASTYEAR('OF Page Date Dimension'[CALENDAR_DATE]))

 

The purpose is to show a chart with date as the x axis, and number of fundraising pages this year compared to this time last year. This will look something like the below:

 chart_example.PNG

 

 

 

 

I have a chart which to me is doing something very similar, but is performing fine - can anyone help tweak/fix this for me?

 

Thanks

Alex

1 ACCEPTED SOLUTION
alexei7
Continued Contributor
Continued Contributor

It turned out that having an intermediary table was causing the performancy issues.

 

A simplified version of my data model looks like this:

 

Date Dimension --- Page ---- Fundraising Page

 

Thankfully I was able to change the COUNTROWS to count the "Page" table not the "Fundraising Page" table - and by adding an extra filter, achieve almost the same result.

 

We guessed that maybe there was some kind of loop caused by the combination of the TOTALYTD and SAMEPERIODLASTYEAR functions (as well as the data model obviously) which meant that the performance was so slow.

View solution in original post

4 REPLIES 4
Greg_Deckler
Community Champion
Community Champion

Example data might help. You might try creating a New Table and use CALCULATETABLE with the individual parts of your filter to see if you can identify what part is causing it to be slow/exceed resources.

 

Also, if that is a measure, I would have though you would need an aggregator around pages[page_status], is this a column?



Follow on LinkedIn
@ me in replies or I'll lose your thread!!!
Instead of a Kudo, please vote for this idea
Become an expert!: Enterprise DNA
External Tools: MSHGQM
YouTube Channel!: Microsoft Hates Greg
Latest book!:
DAX For Humans

DAX is easy, CALCULATE makes DAX hard...
alexei7
Continued Contributor
Continued Contributor

Thanks for your help smoupre.

 

What do you mean by "need an aggregator around pages[page_status]"?

Yes, this is a column, and i'm only interested in rows from the related table which have a page_status not equal to 2.

 

Thanks again

Alex

OK, if it is a column, you don't need an aggregator like SUM, COUNT, etc. like you would in a measure. 

 

If the table is related, perhaps use RELATEDTABLE or RELATED?



Follow on LinkedIn
@ me in replies or I'll lose your thread!!!
Instead of a Kudo, please vote for this idea
Become an expert!: Enterprise DNA
External Tools: MSHGQM
YouTube Channel!: Microsoft Hates Greg
Latest book!:
DAX For Humans

DAX is easy, CALCULATE makes DAX hard...
alexei7
Continued Contributor
Continued Contributor

It turned out that having an intermediary table was causing the performancy issues.

 

A simplified version of my data model looks like this:

 

Date Dimension --- Page ---- Fundraising Page

 

Thankfully I was able to change the COUNTROWS to count the "Page" table not the "Fundraising Page" table - and by adding an extra filter, achieve almost the same result.

 

We guessed that maybe there was some kind of loop caused by the combination of the TOTALYTD and SAMEPERIODLASTYEAR functions (as well as the data model obviously) which meant that the performance was so slow.

Helpful resources

Announcements
August Power BI Update Carousel

Power BI Monthly Update - August 2025

Check out the August 2025 Power BI update to learn about new features.

August 2025 community update carousel

Fabric Community Update - August 2025

Find out what's new and trending in the Fabric community.