@Byron Antoniadis Thank you for sharing the information. I have done some initial investigation and so far, the issue seems to be slightly different. At least from the error:

{
  "title": "Bad Request",
  "status": 400,
  "detail": "An error has occurred while calculating the result",
  "resultId": "e4d97221692181f4fc102e34dc770432e32fd76f",
  "reason": "Query timeout occurred",
  "traceId": "55c85b0412bf68bc65e4b28cfaa5badb"
}

That states that is has been caused by the query timeout. Is this customer somehow "different" from the others? E.g. in the amount of records or data? In addition, I reached out to the developers in order to discuss further the other possible reasons for this strange behaviour in only one of the child workspaces.

Thanks @Branislav Slávik - the weird thing is that for other clients with far more data (check workspace “Laskaridis”), it succeeds. That’s why I think it’s weird

Hi Byron, I am in touch with our developers regarding the issue. They confirmed that the issue is different than the initial one before and that the timeout indeed happens on the Postgres side. The SQL queries take longer than 160s to finish, For now, we can only guess what causes the queries to take significant time to execute just for this particular workspace / customer. Would it be possible for you to find the problematic report queries and execute them manually in Postgres with

EXPLAIN ANALYZE

? The idea would be to compare the execution plans of the statement(s) / queries to see if there are any differences, e.g. between workspaces of different customers.

Hello - I have run the

EXPLAIN ANALYZE

for the

Production parent workspace

(contains ALL data for ALL clients and works!!!) and the specific failing workspace

Meadway

and the SQL statement for Meadway runs much faster & the only diff in the analyze is applying the

shipco_id

filter. I do not know where to go from here, so I’ll need your help. It’s extremely weird that the superset workspace works and the subset doesn’t

Hi Byron, apologies for missing the updates here. Let me have a look into it a bit and I will get back to you before EoD.

Here you are, please go through the document and let me know if you have any qs/points for discussion

Hi @Byron Antoniadis, thank you for sharing the query details. I guess it won't be needed anymore, but it is good to have it here for future reference. I am glad that we were able to fix the issue by updating the

year

filter for this dataset. Was the fix / update similar or the same as the one recommended earlier? https://gooddataconnect.slack.com/archives/C01UR5BGAHY/p1739199906643769?thread_ts=1738832429.525059&cid=C01UR5BGAHY Thank you very much for sharing your feedback with us. I will pass it to our product team for their consideration.

@Branislav Slávik I had changed all years to be INT, however in one model it was still an NUMERIC and I had to explicitly change it to INT. However, what boggles my mind is how was this affecting only one workspace 🤯

@Byron Antoniadis, unfortunately, I do not have any exact explanation for that. However, I found some forums / pages over the internet that might explain it. 🤓 It seems that the NUMERIC type is way larger (12 bytes) compared to INT (4 bytes). Also, the performance of some operations is slower: https://dba.stackexchange.com/questions/110880/numeric-vs-integer-for-a-column-size-and-performance https://stackoverflow.com/questions/58155982/what-is-the-difference-between-numeric9-0-and-int-in-postgres In this article, they even tried to measure it and it appears to be ~ 50% to 70% slower performance: https://medium.com/xendit-engineering/benchmarking-pg-numeric-integer-9c593d7af67e#:~:text=Synopsis,more%20time%20than%20integer%20types.