Comment 22 for bug 1935037

Personally, no. I've tested with ~10, not hundreds, of group fields.

I don't know of any reason why it won't "work" in the strictest sense of not crashing, and eventually yielding consistent data. My curiosity is about performance. There is a strong application specific component here as groups tie in with locking is done with database records (aka. dbScanLock() ).

When a group is read out, on GET or when a monitor update is triggered, QSRV will lock *all* of the individual records in *sequence*. This means waiting for any record processing to complete, and preventing subsequent processing. So inclusion in a group couples scan times of the constituent records with each other, and with QSRV.

The worst case time to read out a group is the sum of the worst case processing times of the constituent records in isolation. Further, because the constituents are no longer in isolation, this also becomes the worst case scan time of each record. Each might have to wait for all the others, and QSRV.