Incremental CAgg Refresh Policy

[fabriziomello]

Nowadays a Continuous Aggregate refresh policy process everything only once independent of how large the refresh window is. For example if you have a hypertable with a huge amount of rows it can take a lot of time and requires a lot of resources in terms of CPU, Memory and I/O to refresh a CAgg, and all the aggregated data will be visible for the users only when the refresh policy complete it execution.

This PR add the capability of a CAgg refresh policy be executed incrementaly in "batches". Each "batch" is an individual transaction that will process a small fraction of the entire refresh window, and once the "batch" finishes the execution the data refreshed will already be visible for the users even before policy execution end.

To tweak and control the incremental refresh some new options was added to add_continuous_aggregate_policy API:

• buckets_per_batch: number of buckets to be refreshed by a "batch". To summarize this value is multiplied by the CAgg bucket width to determine the size of the batch range. Default value is 0 (zero) that means it will keep the current behavior of single batch execution. Values less than 0 (zero) are not allowed.
• max_batches_per_execution: maximum number of batches to be executed by a policy execution. This option is used to limit the number of batches processed by a single policy execution, so if some batches remain next time the policy run they will be processed. Default value is 10 (ten) that means that each job execution will process the maximum of ten batches. To make it unlimited then the value should be 0 (zero). Values less than 0 (zero) are not allowed.

[codecov]

Codecov Report

Attention: Patch coverage is 82.60870% with 32 lines in your changes missing coverage. Please review.

Project coverage is 81.89%. Comparing base (59f50f2) to head (a1d1109).
Report is 811 commits behind head on main.

Files with missing lines	Patch %	Lines
tsl/src/continuous_aggs/refresh.c	79.13%	9 Missing and 15 partials ⚠️
tsl/src/bgw_policy/continuous_aggregate_api.c	84.21%	2 Missing and 1 partial ⚠️
tsl/src/bgw_policy/job.c	89.65%	0 Missing and 3 partials ⚠️
src/ts_catalog/continuous_agg.c	80.00%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7790      +/-   ##
==========================================
+ Coverage   80.06%   81.89%   +1.82%     
==========================================
  Files         190      247      +57     
  Lines       37181    45685    +8504     
  Branches     9450    11431    +1981     
==========================================
+ Hits        29770    37412    +7642     
- Misses       2997     3776     +779     
- Partials     4414     4497      +83     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mkindahl]

Some minor comments. Since it is in draft, I will wait with approving until you have the final version.

[mkindahl]

A few questions regarding some parts of the code where I am not sure if it is correct or not.

[gayyappan]

• max_batches_per_execution: maximum number of batches to be executed by a policy execution. This option is used to limit the number of batches processed by a single policy execution, so if some batches remain next time the policy run they will be processed. Default value is 10 (ten) that means that each job execution will process the maximum of ten batches. Values less than 0 (zero) are not allowed.
  Why not let the default behavior process all batches ? That behavior is more intuitive than restricting this to a predefined number of batches for every policy run.

[fabriziomello]

• max_batches_per_execution: maximum number of batches to be executed by a policy execution. This option is used to limit the number of batches processed by a single policy execution, so if some batches remain next time the policy run they will be processed. Default value is 10 (ten) that means that each job execution will process the maximum of ten batches. Values less than 0 (zero) are not allowed.
  Why not let the default behavior process all batches ? That behavior is more intuitive than restricting this to a predefined number of batches for every policy run.

The default behavior will process all batches, this option will make sense ONLY when buckets_per_batch>0. The idea of this advanced configuration is to somehow reduce resource consumption spikes during the refresh and we made this assumption to limit processing 10 batches per execution. We can make it unlimited by setting it to 0 (zero) but we really don't know now what is a good value for it so we're making it conservative so you should explicit upper limit the maximum batches to be processed when setting a value greater than zero to buckets_per_batch.