Re: Stale hash entries when reusing an auxiliary resource owner

Hi,

Thanks for the comments.

> It will be interesting to benchmark the overhead of clearing these entries
> during ResourceOwnerSort and ResourceOwnerRelease.
>
> Assuming no significant performance impact, I think it makes more
> sense to reset the entries where they are being compacted out or
> released instead of introducing a new API
> function for the same. It also guarantees that entries are cleared
> even if an error occurs before they are reset.
> I am planning to review the patches in detail.

I used GCC 10.2.1 with CFLAGS=-O2,
--disable-debug --disable-cassert.

All microbenchmark cases below use one resource kind. Columns are:

Timing: Release = all three release phases;
Reset = Reset alone after release has completed.
Live/peak: resource count before release / peak registered count.
For Reset, the peak is established before timing.
Baseline: unpatched.
A: clear hash entries during sorting and bulk release.
B: clear the retained hash table in Reset.

Values are median microseconds per owner. The baseline has no Reset
API, so those measurements are marked with a dash.

| Timing | Live/peak | Baseline | A | B |
+----------+-------------+-----------+-----------+-----------+
| Release | 0/0 | 0.026 | 0.029 | 0.027 |
| Release | 16/16 | 0.108 | 0.116 | 0.107 |
| Release | 32/32 | 0.202 | 0.207 | 0.198 |
| Release | 33/33 | 0.282 | 0.277 | 0.268 |
| Release | 64/64 | 0.463 | 0.466 | 0.456 |
| Release | 128/128 | 0.954 | 0.977 | 0.939 |
| Release | 1024/1024 | 11.617 | 11.341 | 11.825 |
| Release | 16384/16384 | 239.506 | 256.352 | 237.873 |
| Release | 0/1024 | 0.040 | 0.044 | 0.038 |
| Release | 16/1024 | 2.051 | 1.790 | 1.854 |

For Release, the smaller cases tested show small absolute differences.
The difference is more apparent with 16,384 resources.

| Timing | Live/peak | Baseline | A | B |
+----------+-------------+-----------+-----------+-----------+
| Reset | 16/16 | - | 0.005 | 0.006 |
| Reset | 64/64 | - | 0.005 | 0.054 |
| Reset | 1024/1024 | - | 0.008 | 0.570 |
| Reset | 16/1024 | - | 0.005 | 0.706 |
| Reset | 16/16384 | - | 0.013 | 14.698 |
| Reset | 16/65536 | - | 0.023 | 66.911 |

For Reset, B's cost grows with retained hash capacity. An earlier high
peak can therefore make later resets expensive even with few current
resources. The large historical peaks are deliberate stress cases.

To check whether A's extra release work affects SQL throughput,
I also ran pgbench -S -M prepared -c 1 -j 1 at scale 1. TPS values
below are medians; differences compare those medians with baseline.

+----------+------------+------------+--------+
| Run | Baseline | A | A diff |
+----------+------------+------------+--------+
| First | 43736.94 | 43035.63 | -1.60% |
| Repeat | 43340.50 | 43574.31 | +0.54% |
+----------+------------+------------+--------+

The first run used seven trials of 12 seconds with each build's
client. The repeat used five trials of eight seconds with one client
binary for all servers. The TPS differences change direction between
runs, and I did not observe a consistent throughput regression in
this workload.

Given these results, I prefer clearing during sorting and bulk
release. It avoids clearing the full retained table in Reset, and
these pgbench runs did not show a consistent throughput regression.
Attached with v4.

Regards,
Jingtang