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