Re: Question about lazy_space_alloc() / linux over-commit - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Question about lazy_space_alloc() / linux over-commit
Date
Msg-id 20150307224921.GV30405@awork2.anarazel.de
Whole thread Raw
In response to Re: Question about lazy_space_alloc() / linux over-commit  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Question about lazy_space_alloc() / linux over-commit  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Question about lazy_space_alloc() / linux over-commit  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015-03-05 15:28:12 -0600, Jim Nasby wrote:
> I was thinking the simpler route of just repalloc'ing... the memcpy would
> suck, but much less so than the extra index pass. 64M gets us 11M tuples,
> which probably isn't very common.

That has the chance of considerably increasing the peak memory usage
though, as you obviously need both the old and new allocation during the
repalloc().

And in contrast to the unused memory at the tail of the array, which
will usually not be actually allocated by the OS at all, this is memory
that's actually read/written respectively.

I've to say, I'm rather unconvinced that it's worth changing stuff
around here. If overcommit is enabled, vacuum won't fail unless the
memory is actually used (=> no problem). If overcommit is disabled and
you get memory allocations, you're probably already running awfully
close to the maximum of your configuration and you're better off
adjusting it.  I'm not aware of any field complaints about this and thus
I'm not sure it's worth fiddling with this.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Bootstrap DATA is a pita
Next
From: Andrew Dunstan
Date:
Subject: Re: Bootstrap DATA is a pita