Phil would you elaborate a little on the above comment, what is considered a low threshold?
In the context of that post, anything that would cause the maximum number of batch write behind instances to exist in regular operating conditions.
I noticed your remark about streaming as opposed to loading the entire period's values in memory, Are there any plans to move in this direction?
I can't say if anyone will want to change anything about it, but I began I REST controller that did streaming values (or optionally load them all), generating multiple points' histories in one request, and provided the ability to cancel a history generation task. There was some stuff left there to be finished / fixed up, but I'm sure some more feature-ful REST controller is on its way.
I also remember something discussed in another thread about automatically regenerating the missing metapoints whenever the source data sync runs; Is there any motivation within your collective talents to create this feature?
Possible, but unlikely. I don't think you should have meta points on the receiver end unless you really cannot have them on the publisher's side. You could already take that history generation loop I gave you (invokes the meta edit dwr from a loop of points to generate iirc) and place that into a set point event handler for the persistent receiver's sync completed event. So, in that sense it is possible and not my favorite idea, so I'm unlikely to encourage it further without good cause.
There some discussion of this in this thread: https://forum.infiniteautomation.com/topic/3189/using-persistent-tcp-points-in-script-calculations
