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)
Список
Дерево обсуждения
Explanation for bug #13908: hash joins are badly broken Tom Lane <tgl@sss.pgh.pa.us>
Re: Explanation for bug #13908: hash joins are badly broken Stephen Frost <sfrost@snowman.net>
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 Tom Lane <tgl@sss.pgh.pa.us>
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 Andres Freund <andres@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 Tom Lane <tgl@sss.pgh.pa.us>
Re: Explanation for bug #13908: hash joins are badly broken Tom Lane <tgl@sss.pgh.pa.us>
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 Tom Lane <tgl@sss.pgh.pa.us>
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 Robert Haas <robertmhaas@gmail.com>
Re: Explanation for bug #13908: hash joins are badly broken Tom Lane <tgl@sss.pgh.pa.us>
Re: Explanation for bug #13908: hash joins are badly broken Tom Lane <tgl@sss.pgh.pa.us>
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 по дате отправления
От: Tomas Vondra
Дата:
От: Tomas Vondra
Дата: