Re: Kevin Grittner 2014-07-01 <1404213492.98740.yahoomail...@web122306.mail.ne1.yahoo.com> > Andres Freund <and...@2ndquadrant.com> wrote: > > On 2014-07-01 11:01:04 +0200, Christoph Berg wrote: > > >> How much difference would it make if numactl --interleave=all > >> was used instead of using numa_interleave_memory() on the shared > >> memory segments? I guess that would make backend-local memory > >> also interleaved, but it would avoid having a dependency on > >> libnuma in the packages. > > > > I've tested this a while ago, and it's rather painful if you have > > a OLAP workload with lots of backend private memory. > > I'm not surprised; I would expect it to generally have a negative > effect, which would be most pronounced with an OLAP workload.
Ok, then +1 on having this in core, even if it buys us a dependency on something that isn't in the usual base system after OS install. > > I wonder if we shouldn't backpatch such a notice. > > I would want to see some evidence that it was useful first. In > most of my tests the benefit of interleaving just the OS cache and > PostgreSQL shared_buffers was about 2%. That could easily be > erased if work_mem allocations and other process-local memory were > not allocated close to the process which was using it. > > I expect that the main benefit of this proposed patch isn't the 2% > typical benefit I was seeing, but that it will be insurance against > occasional, much larger hits. I haven't had much luck making these > worst case episodes reproducible, though. Afaict, the numactl notice will only be useful as a postscriptum to the --with-libnuma docs, with the caveats mentioned. Or we backpatch (something like) the full docs of the feature, with a note that it's only 9.5+. (Or the full feature gets backpatched...) Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers