From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org,  jakub.janecek@comgate.cz
Subject: Re: BUG #15486: PG11 jit on 50x slower than jit off
In-Reply-To: <20181122015409.i4jd6e2ypwmbkyu5@alap3.anarazel.de> (Andres
	Freund's message of "Wed, 21 Nov 2018 17:54:09 -0800")
Message-ID: <87k1l5sl7l.fsf@news-spur.riddles.org.uk>
References: <15486-05850f065da42931@postgresql.org>
	<20181122015409.i4jd6e2ypwmbkyu5@alap3.anarazel.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix)
Date: Thu, 22 Nov 2018 06:26:12 +0000
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

>>>>> "Andres" == Andres Freund <andres@anarazel.de> writes:

 Andres> This actually isn't great outside of JIT compilation as well -
 Andres> we waste a substantial portion of time rebuilding the
 Andres> expression everytime, and the hashtable grows every time as
 Andres> well.

Why would the hashtable grow? All of BuildTupleHashTable's callers
follow this pattern: the hashtable is allocated in a memory context that
will be reset on every rescan. Everything the hash table initialization
does is assumed to be completely discardable.

Which means that if you want to add a ResetTupleHashTable, it'll mean
significant reorganization of the callers' use of memory contexts, since
the hashtable will have to go into per-query memory (and presumably
create a child context of its own).

(There's an implicit assumption by all of BuildTupleHashTable's callers
that it will not allocate anything outside of the passed-in tablecxt,
which will be reset. Having BuildTupleHashTable allocate anything in its
caller's context is effectively an API break. But I notice this
_already_ got broken in pg11: the ExprContext that now gets allocated in
BuildTupleHashTable will be leaked into per-query memory on each cycle.)

-- 
Andrew (irc:RhodiumToad)