Re: BUG #15486: PG11 jit on 50x slower than jit off
От | Andrew Gierth |
---|---|
Тема | Re: BUG #15486: PG11 jit on 50x slower than jit off |
Дата | |
Msg-id | 87k1l5sl7l.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: BUG #15486: PG11 jit on 50x slower than jit off (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
>>>>> "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)
В списке pgsql-bugs по дате отправления: