Re: Registering LWTRANCHE_PARALLEL_HASH_JOIN - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Registering LWTRANCHE_PARALLEL_HASH_JOIN
Date
Msg-id CAEepm=3g1hhbFzYkR_QT9RmBvsGX4UaeCtX-4Js8OOEMmFeaSQ@mail.gmail.com
Whole thread Raw
In response to Re: Registering LWTRANCHE_PARALLEL_HASH_JOIN  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Registering LWTRANCHE_PARALLEL_HASH_JOIN  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Feb 28, 2018 at 8:39 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Feb 10, 2018 at 6:07 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> I forgot to register a display name for LWTRANCHE_PARALLEL_HASH_JOIN,
>> the tranche ID used by the LWLock that Parallel Hash uses when handing
>> out chunks of memory.  Please see attached.
>
> I think that you need to insert some weasel words into the
> documentation for this, because I don't think it's really accurate to
> say that it's only used when trying to acquire a new chunk of memory.
>
> Or maybe I'm wrong and it's altogether accurate ... but
> ExecParallelHashMergeCounters doesn't look like an allocation to me,
> and ExecParallelHashTuplePrealloc doesn't really look like an
> allocation either.

Ok.  How about this?

I noticed that some of the descriptions don't attempt to explain what
activity the lock protects at all, they just say "Waiting for $BLAH
lock".  I went the other way and covered the various different uses.
There are 4 uses for the lock but only three things in my list,
because I think "allocate" covers both ExecParallelHashTupleAlloc()
and ExecParallelHashTuplePrealloc().

-- 
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unexpected behavior with transition tables in update statement trigger
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] [bug-fix] Cannot select big bytea values (~600MB)