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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
