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
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 |