Re: Explanation for bug #13908: hash joins are badly broken
От | Andres Freund |
---|---|
Тема | Re: Explanation for bug #13908: hash joins are badly broken |
Дата | |
Msg-id | 20160206193956.GB21471@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Explanation for bug #13908: hash joins are badly broken (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: Explanation for bug #13908: hash joins are badly broken
|
Список | pgsql-hackers |
On 2016-02-06 20:34:07 +0100, Tomas Vondra wrote: > On 02/06/2016 06:47 PM, Tom Lane wrote: > >* It incorporates a bespoke reimplementation of palloc into hash > >joins. This is not a maintainable/scalable way to go about reducing > >memory consumption. It should have been done with an arm's-length API > >to a new type of memory context, IMO (probably one that supports > >palloc but not pfree, repalloc, or any chunk-header-dependent > >operations). > > Hmmm, interesting idea. I've been thinking about doing this using a memory > context when writing the dense allocation, but was stuck in the "must > support all operations" mode, making it impossible. Disallowing some of the > operations would make it a viable approach, I guess. FWIW, I've done that at some point. Noticeable speedups (that's what I cared about), but a bit annoying to use. There's many random pfree()s around, and then there's MemoryContextContains(), GetMemoryChunkContext(), GetMemoryChunkSpace() - which all are pretty fundamentally incompatible with such an allocator. I ended up having a full header when assertions are enabled, to be able to detect usage of these functions and assert out. I didn't concentrate on improving memory usage, but IIRC it was even noticeable for some simpler things. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: