Improve cagg watermark caching

[erimatnor]

The internal function cagg_watermark returns the last/max bucket in
a continuous aggregate and is used to get the point where to union the
raw and materialized data when using real-time aggregation.

Since the function is marked STABLE the planner should be able to
constify the function so that it need not be called repeatedly during
execution. However, this optimization is not guaranteed and the
function might be constified many times during planning if it occurs,
e.g., as an index scan condition on many chunks. This leads to slow
queries due to repeated calls to the function.

Previously, the watermark was cached in the function's fn_extra
state, but this state doesn't survive all repeated calls of the
function and doesn't help if the function occurs many times in the
same plan.

To make the performance more reliable, the watermark is now cached in
a global variable that is cleared at transaction end, when the input
argument (materialized hypertable queried) changes, or a new command
is executed. This should guarantee that the watermark only needs to be
looked up once per query.

Fixes #2826

[codecov]

Codecov Report

Merging #2828 (09bf94a) into master (19d3912) will increase coverage by 0.12%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2828      +/-   ##
==========================================
+ Coverage   90.07%   90.19%   +0.12%     
==========================================
  Files         212      212              
  Lines       34760    34721      -39     
==========================================
+ Hits        31309    31316       +7     
+ Misses       3451     3405      -46     

Impacted Files	Coverage Δ
src/continuous_agg.c	90.64% <100.00%> (+0.25%)	⬆️
src/bgw/scheduler.c	82.59% <0.00%> (-0.89%)	⬇️
src/loader/bgw_message_queue.c	87.09% <0.00%> (-0.65%)	⬇️
src/import/planner.c	70.30% <0.00%> (+11.12%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 19d3912...09bf94a. Read the comment docs.

[pmwkaa]

looks good

[gayyappan]

Changes look good. Made a few suggestions to add to the test.

[mkindahl]

Good job on the tests, I think it covers the situations. Would be good if there were a way to check that the cached variable is really gone after the transaction (e.g., a separate test function that calls watermark_valid or so), but that is a stretch.

[erimatnor]

Good job on the tests, I think it covers the situations. Would be good if there were a way to check that the cached variable is really gone after the transaction (e.g., a separate test function that calls watermark_valid or so), but that is a stretch.

I thought about that, but it requires additional boilerplate code to essentially test that PostgreSQL memory context callbacks work the way they should. I did manually test this, FWIW.

I think we mostly care about returning the "right" watermark (as opposed to being reset after a transaction), which is covered by tests by calling the function multiple times after changes in the materialization table. I think we care less about what happens outside a transaction. The only concern there would be a memory leak, I guess; but then we are testing memory contexts.