Understanding Historian Retrieval Path for FULL/Delta vs Cyclic Queries

For the BESTFIT, MIN, MAX, CYCLIC, INTEGRAL, AVERAGE retrieval modes the historian OLE-DB provider is trying to use the AUTOSUMMARYDATA mode by default, without knowing if the auto-summary subsystem is enabled or not. Since you have it disabled, the retrieval will actually use PRIMARYDATA in this case.  You can run your query with additional parameter wwOption='PRIMARYDATA' to check if there is any difference in results. It is expected that the results and the query execution time will remain the same.

Thank you for the answer, So the result i shared in the image could be misleading, I mean even though data being fetched from primary it shows Auto summary in the result. as we are using cyclic retrieval.

Real purpose to ask this query is i wanted to shows some data in graphana dashboard and i wanted to make sure query fetched data from Auto Summary block and not the primary block. In that can I believe what i have to do it enable AutoSummarize and query using "cyclic", is that enough?

I do not want historian server to be loaded using primary data query, Is my understanding correct?

Thank you!

I do not understand why you have the auto-summary subsystem disabled if you do not want to load the historian with the primary data queries. Using the auto-summary subsystem can speed up your cyclic queries when your cycle duration starts exceeding a few hours in queries of a very long duration like months or years when your primary data is very dense (like changing every few seconds).  The wwOptions column in your screenshot shows AUTOSUMMARYDATA because the OLE-DB provider tries to use the auto-summary data first for that CYCLIC query, not because the retrieved data actually came from auto-summary history blocks. If your auto-summary subsystem is disabled, then there should be no auto-summary history blocks, and not even the auto-summary storage running to perform low-level retrieval operations from those blocks.  I agree that this behavior of the historian OLE-DB provider may be considered confusing, because the user might expect that it tells that every row comes from a disabled auto-summary subsystem, while actually it does not, but this is how it works as of today, and it would require logging an enhancement request for the historian product to have that current behavior changed.

I do not understand why you have the auto-summary subsystem disabled if you do not want to load the historian with the primary data queries. Using the auto-summary subsystem can speed up your cyclic queries when your cycle duration starts exceeding a few hours in queries of a very long duration like months or years when your primary data is very dense (like changing every few seconds).  The wwOptions column in your screenshot shows AUTOSUMMARYDATA because the OLE-DB provider tries to use the auto-summary data first for that CYCLIC query, not because the retrieved data actually came from auto-summary history blocks. If your auto-summary subsystem is disabled, then there should be no auto-summary history blocks, and not even the auto-summary storage running to perform low-level retrieval operations from those blocks.  I agree that this behavior of the historian OLE-DB provider may be considered confusing, because the user might expect that it tells that every row comes from a disabled auto-summary subsystem, while actually it does not, but this is how it works as of today, and it would require logging an enhancement request for the historian product to have that current behavior changed.

 Yevgeny Naryzhny This gives me clarify, Thank you very much. Regarding the Auto Summary disable, I purposely did it jo just verify data comes from which block. I have enable it later on.

Also keep in mind that auto summary is done in hourly resolution. So the example which has a 5 minute timespan will fetch primary data anyway.