Обсуждение: Registering LWTRANCHE_PARALLEL_HASH_JOIN
Hi, 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. It's rare for this LWLock to show up in pg_stat_activity, but if you stick pg_usleep(10000) into ExecParallelHashTupleAlloc() after the lock is acquired (the slow path where a new 32KB chunk is needed) and run some parallel hash joins, then you'll see that pg_stat_activity reports that as "extension" in unpatched master. -- Thomas Munro http://www.enterprisedb.com
Вложения
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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
Вложения
On Tue, Feb 27, 2018 at 3:58 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > 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(). Well, the trouble with that of course is that if something changes later then we have to update the docs, whereas if we keep it vague then we avoid that. But I've committed that version as you have it and maybe by the time it needs to be updated they'll have made you a committer and you can be the poor shmuck who has to spend time committing fixes like this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company