On Wed, Aug 02, 2023 at 06:34:15PM +0900, Masahiro Ikeda wrote: > On 2023-08-01 12:23, Andres Freund wrote: >> This is why the scheme as implemented doesn't really make sense to me. >> It'd be >> much easier to use if we had a shared hashtable with the identifiers >> than >> what's been merged now. >> >> In plenty of cases it's not realistic for an extension library to run in >> each >> backend, while still needing to wait for things. > > OK, I'll try to make a PoC patch.
Hmm. There are a few things to take into account here: - WaitEventExtensionShmemInit() should gain a dshash_create(), to make sure that the shared table is around, and we are going to have a reference to it in WaitEventExtensionCounterData, saved from dshash_get_hash_table_handle(). - The hash table entries could just use nextId as key to look at the entries, with entries added during WaitEventExtensionNew(), and use as contents the name of the wait event. We are going to need a fixed size for these custom strings, but perhaps a hard limit of 256 characters for each entry of the hash table is more than enough for most users? - WaitEventExtensionRegisterName() could be removed, I guess, replaced by a single WaitEventExtensionNew(), as of: uint32 WaitEventExtensionNew(const char *event_name); - GetWaitEventExtensionIdentifier() needs to switch to a lookup of the shared hash table, based on the eventId. All that would save from the extra WaitEventExtensionRegisterName() needed in the backends to keep a track of the names, indeed. -- Michael
signature.asc
Description: PGP signature