Starting December 3, join live sessions with database experts and the Microsoft product team to learn just how easy it is to get started
Learn moreGet certified in Microsoft Fabric—for free! For a limited time, get a free DP-600 exam voucher to use by the end of 2024. Register now
In order to make load time faster during the testing phase I'd like to filter the data and work on a subset.
Unfortunately after I applied a filtering criteria that should filter out 80% of the data, I still see that PBI loads the exact same volume of data.
Why is that?
How can I reduce the amount of data I work with during the dev phase (besides exporting to Excel and reimporting a filtered out csv...)
thanks
Solved! Go to Solution.
Then the filter will not be able to affect the load-process, as no query-folding will take place on this source.
Subsequent calculations should be faster, (but not necessarily, as the commands will be translated to an internal execuation plan that the user cannot influence).
Try using a Table.Buffer for your filter-expression.
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Hi osqinquinvdm
If you use a DB, please check in the Query Editor, if Query folding is broken.
Are you connecting to a SQL-server or what is your data source?
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
The source is a simple csv with next to zero processing
Then the filter will not be able to affect the load-process, as no query-folding will take place on this source.
Subsequent calculations should be faster, (but not necessarily, as the commands will be translated to an internal execuation plan that the user cannot influence).
Try using a Table.Buffer for your filter-expression.
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Thanks for your comments. Where can I find further details on that "query folding" aspect
This is an excellent article: https://www.mssqltips.com/sqlservertip/3635/query-folding-in-power-query-to-improve-performance/
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Where are you basing that notion? On the count of rows in the table, on the size of the PBIX file, ?
on what the pop-up window says and on the time it takes.
thanks for jumping in
Might be related to what type of filter you are using. Is it a date field filter? I have seen some weirdness with that. My first question would be, is it really importing everything. So, if you create a quick COUNT aggregation or look at the bottom of Desktop client in the data area, how many rows do you get with and without the filter in the final table? Does it match what is being reported in the pop-up. If those are the same with and without and match the pop-up, then my guess would be that your filter isn't doing what you think it is doing. If the final row counts in the table are different but the pop-up is the same number, then it might have something to do with the date filter weirdness I mentioned.
Starting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early Bird pricing ends December 9th.
User | Count |
---|---|
90 | |
87 | |
84 | |
68 | |
49 |
User | Count |
---|---|
131 | |
111 | |
96 | |
71 | |
67 |