On 2023-08-08 08:54, Michael Paquier wrote:
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.

Thank you for pointing the direction of implementation.

I am thinking a bit that we also need another hash where the key
is a custom string. For extensions that have no dependencies
with shared_preload_libraries, I think we need to avoid that WaitEventExtensionNew() is called repeatedly and a new eventId
is issued each time.

So, is it better to have another hash where the key is
a custom string and uniqueness is identified by it to determine
if a new eventId should be issued?

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION


Reply via email to