Re: add function for creating/attaching hash table in DSM registry

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Florents Tselai <florents(dot)tselai(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: add function for creating/attaching hash table in DSM registry
Date: 2025-06-10 18:32:55
Message-ID: CAA5RZ0sRkH8PfbwFPpYiqQWmSYmbH+Bd0Vro+YZFvwxzed_6eQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I'm not quite following your uneasiness with the tranche names. For the
> dshash table, we'll need a tranche for the DSA and one for the hash table,
> so presumably any wait events for those locks should be named accordingly,
> right?

I may be alone in this opinion, but I prefer the suffixless tranche name for
the primary LWLock (the hash table), as this is the lock users will encounter
most frequently in wait events, like when adding or looking up entries.

Adding a suffix (e.g., "Hash") may be confusing to the extension. In the tests
that I did with pg_stat_statements, I’d rather see "pg_stat_statements" remain
as-is, rather than "pg_stat_statements Hash".

On the other hand, adding a suffix to the DSA tranche name (e.g.,
"pg_stat_statements DSA") is necessary to differentiate it from the Hash
tranche name, and that is OK because it's not likely to be a user-visible wait
event.

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2025-06-10 19:00:01 Re: strange perf regression with data checksums
Previous Message Konstantin Knizhnik 2025-06-10 18:09:18 Re: Non-reproducible AIO failure