Re: Registering LWTRANCHE_PARALLEL_HASH_JOIN

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Registering LWTRANCHE_PARALLEL_HASH_JOIN
Date: 2018-02-27 20:58:25
Message-ID: CAEepm=3g1hhbFzYkR_QT9RmBvsGX4UaeCtX-4Js8OOEMmFeaSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 28, 2018 at 8:39 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Feb 10, 2018 at 6:07 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)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 Content-Type Size
0001-Register-and-document-LWTRANCHE_PARALLEL_HASH_JOI-v2.patch application/octet-stream 2.4 KB

In response to

Responses

Browse pgsql-hackers by date

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