You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See #3492 for an example, but this is a wider issue that probably happens for most chart types.
We might want to rethink how the entity selector table is constructed. Currently we run transformations of a chart's transformTableForSelection on the input table (except for scatters). This is cumbersome and error-prone. We could try restructuring the tables and transforms such that the entity selector gets the transformed table before entity and time filtering. Of course this would mean that we run (potentially) perf-draining transforms on the unfiltered input table.
The text was updated successfully, but these errors were encountered:
A bit more context on this:
Currently, for many chart types, common first transforms to run on a table are filtering by selected entities, and filtering to the current timeline selection.
The main advantage of this is that the coming transforms may then run on way fewer rows of data. Which can be beneficial, because some transforms like tolerance are quite costly.
See #3492 for an example, but this is a wider issue that probably happens for most chart types.
We might want to rethink how the entity selector table is constructed. Currently we run transformations of a chart's
transformTableForSelection
on the input table (except for scatters). This is cumbersome and error-prone. We could try restructuring the tables and transforms such that the entity selector gets the transformed table before entity and time filtering. Of course this would mean that we run (potentially) perf-draining transforms on the unfiltered input table.The text was updated successfully, but these errors were encountered: