Enable Compression for recalculated Analyses up to "Now"

I don't see the need for adding the restriction of up to" Now" . In my opinion whether they are out of order or live snapshots, all events going into a tag that has compression enabled should go through the compression algorithm. And I don't think this should be restricted to analysis outputs. What is the business case for treating OOO events differently to snapshots with regards to compression?

This feature has been requested in different way numerous times, and would be very useful.

Why not simply implement the compression algorithm inside of the analysis recalculation service itself, rather than changing the behavior of pibufss? Then when a recalculation is performed, you can choose an option to apply compression settings to the calculated values. This seems like what everyone expects to happen anyway.

This would be very useful for me in recalculating summary data from very active source tags (the customer wants all that "data") that result in very compressible data.

Recalculation already support removing all values within a time range. Can you tell me which version you're using?

As the customer responsible for this, I'll expand on that a little: If I create an Analysis creating a simple SawTooth from 0 to 10, triggering every minute, and let it run live the Analysis Service will apply the compression settings to the Archive data (storing only the 0 and the 10). If I "Recalculate" (deleting all the data), the Analysis Service will only apply the compression settings to the last chunk. This is illustrated in this KB article: https://customers.osisoft.com/s/knowledgearticle?knowledgeArticleUrl=Will-PI-Analysis-Recalculation-follow-compression-and-exception This is irrespective of if a newer Snapshot value exists or not. What I expect to happen is that the Analysis Service gives the same result (as long as the input data is the same) when Recalculating and while having the Analysis run live. One Use-Case we have for this is calculating (and storing) the slope of a set value, which slowly, but linearly increases/decreases over many hours. When running live, I can simply use the Rate function and be done. If I ever want to recalculate the Analysis (because the Analysis is new and I want to apply it to the last months or years of data), I have to add a lot of code checking the last stored value with the new value. Otherwise I have hundreds of thousands or millions of values archived instead of a few hundred or few thousand, because compression is not applied. We have the Buffer Subsytem running on the Analysis Server. It applies (or does not apply) the compression.

The problem here is that although you delete archived events through Recalculation (mode: RangeDelete), PI Buffer will preserve its own snapshot value in memory. If you have pibufss on the machine which you are sending data from, then pibufss is responsible for doing compression. PI Buffer Subsystem keeps the information about the most recent value it sent (i.e. local snapshot) and it performs compression only for events which has timestamp more recent than the local snapshot. So even if you delete all events on PIDA and from PIDA point of view events are coming in-order, from pibufss these events are out of order and won't be compressed (if they are older than the pibufss snapshot event). You can check buffer-local snapshot by running the command pibufss -sd ptid where ptid is the Point ID for the tag you are interested in.

So what is needed is a way to remove a single PI Point from the Buffering Subsystem Cache. That way, on the next recalculation, the Analysis Server would treat that PI Point like a newly added PI Point, and first retrieve the current snapshot from the Data Archive.