[00:00] The tag historian system, by default, stores history across multiple data partitions. It can also be configured to prune or delete these partitions after a certain amount of time. This way, the system will be properly maintained with minimal effort. We'll go over some of these settings. I'm going to take a look at the configure section and because we're dealing with historical providers, I am in the tag section of the history page. And I'm going to edit one of my historical providers. It doesn't matter which one of these data source history providers I edit, they have the same settings. I'm going to go ahead and just click the edit button on the right. And we'll scroll down a little further here and talk about the data partitioning properties. Now by default, partitioning is enabled. While enabled, we'll take a look at the partition length and partition units, and this specifies how often we create a new data base table to store your history. Now, just so you can visualize this, I'm going to bring up my SQL workbench real quick and take a look at my schema. And you can see I actually have two partition tables, these sqlt_data tables, containing the tag history data. So I have one for February of 2017, as well as one for March of 2017. The reason we split the data up across multiple partitions like this is for efficiency. As data base tables gain more and more rows, queries against those tables take longer. So it's actually better in the long run to create multiple smaller tables than to have one single gigantic table with millions of rows. Now I'm going to head back to my gateway here, just going to minimize my workbench. If for whatever reason you decide that you don't want partitioning, you can simply turn it off. I'm going to leave this on for now, and we're going to talk about the pre-process partitions next. Once enabled, the system will generate two partitions every time, you don't need to create a new one based on the units in length. In this case, every month, the system will generate a standard partition, and a pre-process partition. This of course requires more hard drive space. The pre-process partitions are summarized versions of the standard partitions that are used when querying for history over a large range of time. How compact the data is depends on the pre-process window size property down below. The benefit of these pre-process partitions is speed. The system can detect when it would be faster to use these summarized partitions over the standard partitions. This means that the results of the query would be returned faster when looking at data over a long range. I'm going to scroll down a bit further here and take a look at the data printing section here. This is if you want the system to automatically delete old partitions. By default it is disabled, so we won't delete those old data tables without your knowing, but of course you can opt into it. If enabled, the system will note the prune age and prune age units property. The system will delete partitions when all rows in that partition are older than the prune age. As the description on the "enable data pruning" states, entire partitions are dropped, so it does not prune some of the rows out of the table, it drops the whole thing. It's an all-or-nothing pruning. If you would rather archive the old history instead of pruning, just make sure to leave the "enable data pruning" property with its default value of false.