Andres Freund <and...@anarazel.de> writes:
> So after all this my question basically is: How important do we think the
> mctx.c abstraction is?
I think it's pretty important. As a specific example, a new context
type in which pfree() is a no-op would be fine with me. A new context
type in which pfree() dumps core will be useless, or close enough to
useless. That means you can't get rid of the per-chunk back-link to the
context, but you might be able to get rid of the other overhead such as
per-chunk size data. (It might be practical to not support
GetMemoryChunkSize for such contexts, or if it's a slab allocator then
you could possibly know that all the chunks in a given block have size X.)
Another point worth making is that it's a nonstarter to propose running
any large part of the system in memory context types that are incapable
of supporting all the debugging options we rely on (freed-memory-reuse
detection and write-past-end-of-chunk in particular). It's okay if a
production build hasn't got that support, not okay for debug builds.
Perhaps you'll propose using completely different context
implementations in the two cases, but I'd be suspicious of that because
it'd mean the "fast" context code doesn't get any developer testing.
> Especially as I hope its possible to write a single allocator
> which is "good enough" for everything.
I'll lay a side bet that that approach is a dead end. If one size fits
all were good enough, we'd not be having this conversation at all. The
point of the mctx interface layer from the beginning was to support
multiple allocator policies, and that's the direction I think we want to
go to improve this.
BTW, what your numbers actually suggest to me is not that we need a
better allocator, but that we need a better implementation of List.
We speculated back when Neil redid List the first time about aggregating
list cells to reduce palloc traffic, but it was left out to keep the
patch complexity down. Now that the bugs have been shaken out it might
be time to have another go at that. In particular, teaching List to
allocate the list head and first cell together would alone remove a
third of your runtime ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
