Re: Improve LWLock tranche name visibility across backends

Hi,

On Mon, Aug 18, 2025 at 05:53:44PM -0500, Sami Imseih wrote:
> > I've been staring at the latest patch for a bit, and I'm a bit concerned
> > at how much complexity it adds.
> 
> The complexity is the fact we have to track a dsa_pointer that points
> to an array of dsa_pointers that track the tranche names. We also
> do have to copy the array of dsa_pointers into a new pointer when
> enlarging. That adds some complexity that dshash would hide away,
> but I don't think it's overly complex.

I also think that's not overly complex but OTOH why add extra complexity if
we have already a machinery at our disposal that takes care of what we need i.e
resizing and so on.

> > I know we were trying to avoid using
> > dshash earlier, if for no other reason than it's perhaps not the best data
> > structure for the job,

I can see that Nathan's concern about dshash was that it could be a bit slower
([1]). That's probably true but that does not worry me that much given that 
adding tranches should be rare enough and the lookups should be rare (to sync the
local cache) and not be that sensible to performance.

> yeah, we really just need an append only structure, so dshash did not
> seems unnecessary. But also, we moved away from dshash before it was
> decided to have a local cache. Perhaps, it's ok now to go back to dshash
> considering that it will only be used in rare scenarios: creations of
> new tranches and
> syncs to local memory. Most of the time the tranches will be satisfied
> directly from local cache.

Yes.

> > (or some other shmem-based
> > data structure we have yet to introduce, like a dslist/dsarray).
> 
> This will be an interesting API to invest time in, if there could be more
> use-cases.

I did a quick check and I did not find current use cases: possible candidates
could be in ExecParallelHashTableAlloc(), PTIterationArray, PTEntryArray for
examples but I think they all know the final size upfront so there is no real
need for dsarray for those).

> I think it's a separate discussion at this point.

OTOH, that would be a valid use case to introduce this new API but I'm not sure
it's worth it given that the dshash looks good enough for our case (even if not
ideal though).

[1]: https://www.postgresql.org/message-id/aHV5BsKoSeOkIsNL%40nathan

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com