Hi GD team. I wanna ask about often errors when loading filters/reports. I’m attaching screenshots to describe the issue and console logs. Usually reload works (but that’s not good end user experience). We are wondering what might be causing those and what can we do prevent these errors (compute boost, DB boost…). We are still using GDCN V2.x and we will be updating to V3 really soon. But we don’t wanna wait and hope that the update will simply fix that, so I’m rather asking already before the update, if this is something you have experience with from the past and other users. If so, if update is the solution or there is some other things we need to implement to help us mitigate those issues. Sorry if this is duplicate issue. I’ve tried to search for it here, but did not manage to find similar reports. Thanks a lot for any advice! cc @Tomáš Kačur

Hi Martin, This is most probably caused by a timeout during the execution. More info could be possible to retrieve from backend logs. This very generic error typically is caused by too slow of a datasource, inefficient SQL queries generated by Calcique component, or missing indexes in datasource DB. Or, simply the logical data model is badly designed. If the dashboard reload sometimes helps it is because the computation had finish already and the new request retrieves data from cache. This is most likely the same for the filters as well. All in all, the error itself won't be fixed with an upgrade, but rather limiting the report size.

Hi Joseph. Thanks for your valuable insights. Those error filters in the example are indeed coming from larger table (over 200M rows). We are using Snowflake as the source DB, so some clustering might help. Besides such optimization, do you have some experience with using Snowfkae DB, so you could recommended DWH size for GDCN? There is not table larger than that. We can test it of course, just looking for some knowledge you can already have in this matter 🙂 Thanks once more!

Hi Martin, 200M rows is quite a lot to visualize. How exactly do you intend on using this data. Could you please provide a full use case? Is there plans to export the data to work with it in this context?

And that number will keep raising 🙂 Yes, we might eventually use some filtered table without the full history. The same table is actually used for exporting (not through GD), so users can analyze the data in IDE etc. We are using the same table for vizualizations, so we are 100% sure the exported data are the same. The report on top of such data (Keboola connection jobs, but you can imagine i.e. orders) is always showing just records from selected period of time and there is also row level filter in place, so you are always accessing only a subset of the data. We aim to use some clustering on that table to speed up the queries (we already had some successful test months ago when testing clustering of DB for faster reports in GD for different use case).

Hi Martin, The execution limits may not allow for this to display, but we are checking if anything can be done to acomodate your usecase.

Thanks Joseph. Seems we are not hitting the limits. We’ve added some clustering to the most used fact tables, upsize the warehouse a bit and that helped a lot 🙂

Hi Martin, Glad to hear! We plan on releasing FlexQuery + pre-aggregations which will also help in your case. However, we don't know exactly when it will be ready, so keep your eyes posted on the release notes