Hi @Hyman_van_Zyl it is very unlikely that the auto-generated virtual columns are where your sync time is going. However, you may think so when you look at the performance profiler, but that is a flaw in how the data is being presented. Let me explain. Letโs say your app has 10 tables. Our server will only fetch a few of them in parallel (the exact number depends on your subscription and the current load, but letโs say that number is 3). So off it goes to fetch tables 1, 2, and 3 in parallel. When any of them is fetched and ready, that thread goes off to fetch 4, and so on.
But now hereโs the tricky part โฆ what happens with virtual columns? The virtual columns for table 1 are computed right after table 1 is fetched. But letโs say one of them requires table 8. So that has to be fetched too. In the performance logs, this will count towards the compute time for the virtual column. But in reality, table 8 had to be fetched anyway at some point during the sync. In fact, youโll see this recorded if you drill down into the virtual column computation in the profiler.
The virtual columns that take a long time to run are those that involve inefficient multi-level SELECT formulas. The โreverse referenceโ formulas are usually really fast โ they just need one pass through the data. And we do this in our server during sync so that we donโt have to do them on the devices (slower and more of a battery drain on a device)
LinkedIn
Twitter
