implement rolling hyper-log-log algorithm

[knizhnik]

Problem

See #7466

Summary of changes

Implement algorithm descried in https://hal.science/hal-00465313/document

Now new GUC is added:
neon.wss_max_duration which specifies size of sliding window (in seconds). Default value is 1 hour.

It is possible to request estimation of working set sizes (within this window using new function
approximate_working_set_size_seconds. Old function approximate_working_set_size is preserved for backward compatibility. But its scope is also limited by neon.wss_max_duration.

Version of Neon extension is changed to 1.4

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[github-actions]

3024 tests run: 2909 passed, 0 failed, 115 skipped (full report)

---

Flaky tests (1)

Postgres 16

• test_statvfs_pressure_usage: debug

Code coverage* (full report)

• functions: 32.6% (6932 of 21267 functions)
• lines: 50.0% (54446 of 108873 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
7df9051 at 2024-07-04T16:39:49.844Z :recycle:}

[MMeent]

Some comments on memory efficiency, and which version we install by default.

[sharnoff]

Some questions, based on discussion from #7466. Not blocking, just trying to get a better understanding:

1. How do you expect this to be used? e.g. should sql-exporter expose a small number of metrics (maybe just n=1?) based on calling approximate_working_set_size_seconds with different values?
2. What's the semantics of the new GUC? (can it be changed at runtime? -- not that I think it needs to be, just curious 😄)
3. Do I understand it correctly that approximate_working_set_size_seconds(N) returns the size estimate for the last N seconds?

[kelvich]

todo: add rollback scripts

[knizhnik]

Some questions, based on discussion from #7466. Not blocking, just trying to get a better understanding:

1. How do you expect this to be used? e.g. should sql-exporter expose a small number of metrics (maybe just n=1?) based on calling approximate_working_set_size_seconds with different values?

Actually, no idea. This is why I have complained in #7466 that I do not understand how autoscaler is going to use this working set size estimation for some period of time.

2. What's the semantics of the new GUC? (can it be changed at runtime? -- not that I think it needs to be, just curious 😄)

There is no GUC any more: I have removed it after @MMeent review. So now window in unlimited - you can request estimation of working set sizer any period from compute startup.

3. Do I understand it correctly that approximate_working_set_size_seconds(N) returns the size estimate for the last N seconds?

Yes