Hello, we are seeing performance issues w/ child workspaces. In particular, the same dashboard takes 1.8 minutes to load on the child, but only ~90 milliseconds on the parent. The filter is:

{
  "workspaceDataFilters": [
    {
      "columnName": "orgId",
      "id": "org-filter",
      "title": "Org Filter",
      "workspace": {
        "id": "main",
        "type": "workspace"
      },
      "workspaceDataFilterSettings": [
        {
          "filterValues": [
            "1"
          ],
          "id": "arrows-up-org-filter",
          "title": "Filter for Arrows Up Data",
          "workspace": {
            "id": "arrows-up",
            "type": "workspace"
          }
        }
      ]
    }
  ]
}

On the child workspace, this data endpoint is really slow. For the parent workspace, the data endpoint is WAY faster.

Hi Michael, there could be a few different reasons for this. You may need to check how many filters are being used on the child dashboard vs the parent as this can contribute to some slowness. Also, if there is more data and more reports to load on the child dashboard, it could take longer. Could you please review these two things on your end, and if you are still facing issues, we can can continue the investigation.

What data source do you use? What data type has the column which you use for the filtering? @Joseph Heun we should be able to explore our Splunk searching for longest running SQL queries in particular organization/workspace. Once we have it, we can compare SQL queries related to the same dashboards in parent/child workspaces and find out what is the root cause.

This child dashboard only has the single data filter (orgId = 1). The child dashboard should be strictly a subset of the data in the parent (I thought this was by design - the child dashboard is uneditable). We are using postgres. All of our physical data models are views (not materialized). This particular view only has 621 rows total. However, I just tried apply the orgId = 1 filter via SQL and it's also slow. So it appears to be a problem with our view. I should have looked into that first! Apologies for the goose chase.

Thank you for letting us know and no need to apologize, really. We are glad that you were able to recognize the source of the slowness. Good luck with optimization of your data source/view.

May be caused by many reasons, but one just came to my mind - If the filter predicate is pushed down to a larger table and the data type of the corresponding column does not match to data type of the value, database may need to apply data type conversion for each row which may be expensive. Another reason can be (and it happens quite often in the case of PostgreSQL) that the query optimizer estimates wrongly the cardinality of aggregations/joins. I would compare explains of both queries.

This ended up being caused by postgres views being poorly optimized when

where "orgId" = 1

was appended to them. By materializing the main view, the problem was fixed.