From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, jakub(dot)janecek(at)comgate(dot)cz |
Subject: | Re: BUG #15486: PG11 jit on 50x slower than jit off |
Date: | 2018-11-22 06:26:12 |
Message-ID: | 87k1l5sl7l.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>>>> "Andres" == Andres Freund <andres(at)anarazel(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | Feike Steenbergen | 2018-11-22 15:50:54 | New sessions on a database to be dropped consume 100% cpu |
Previous Message | Andres Freund | 2018-11-22 01:54:09 | Re: BUG #15486: PG11 jit on 50x slower than jit off |