> > Yeah, I mentioned that earlier, and I did not feel right about it either. > > So I > > added back the test that uses pgstat_drop_entry(), and added a separate > > test function for the new _of_kind API. The TAP test now drops one entry > > via > > pgstat_drop_entry() and another via pgstat_drop_matching_entries_of_kind(). > > > > I also renamed the new static helper to > > pgstat_drop_matching_entries_in_hash() > > to match the existing pgstat_reset_matching_entries_in_hash(). > > My first reaction after reading this patch is why do we need two APIs? > We could have pgstat_drop_matching_entries() take an additional > PgStat_Kind, matching with all the hash tables if passing an invalid > kind?
I initially avoided changing the C API/ABI, which is why the previous version added a separate helper. Since this is only targeting master, I agree that changing pgstat_drop_matching_entries() is better. If there are extensions using pgstat_drop_matching_entries(), it's a simple change. > That would mean one routine instead of three as done in this > patch, as of two exposed and one static in pgstat_shmem.c. That would > also avoid the filter_kind check in the inner loop of > pgstat_drop_matching_entries_in_hash(), as done in the patch. I kept the kind check in the loop because, when kind maps to the shared hash, scanning that hash also visits entries for other kinds. Without the check, a kind-specific scan could consider those entries too, including in the NULL do_drop path. The added tests cover both cases: the callback path verifies that entries of another kind are not passed to the callback, and the NULL do_drop path verifies that dropping all entries of the custom stats kind does not drop a relation stats entry in the same shared hash. -- Sami Imseih Amazon Web Services (AWS)
v3-0001-pgstat-Add-kind-filter-to-pgstat_drop_matching_en.patch
Description: Binary data
