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
Ответ на
Список
Дерево обсуждения
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
Дата:
FAQ