Re: Question about lazy_space_alloc() / linux over-commit

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about lazy_space_alloc() / linux over-commit
Date: 2015-03-07 05:46:42
Message-ID: 5011.1425707202@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Thu, Mar 05, 2015 at 03:28:12PM -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.

> +1. Start far below 64 MiB; grow geometrically using repalloc_huge(); cap
> growth at vac_work_mem.

+1 for repalloc'ing at need, but I'm not sure about the "start far below
64 MiB" part. 64MB is a pretty small amount on nearly any machine these
days (and for anybody who thinks it isn't, that's why maintenance_work_mem
is a tunable). I think min(64MB, vac_work_mem) might be a reasonable
start point.

A different line of thought is that it would seem to make sense to have
the initial allocation vary depending on the relation size. For instance,
you could assume there might be 10 dead tuples per page, and hence try to
alloc that much if it fits in vac_work_mem.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2015-03-07 06:48:28 Re: Question about lazy_space_alloc() / linux over-commit
Previous Message Noah Misch 2015-03-07 05:33:53 Re: Question about lazy_space_alloc() / linux over-commit