Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL and HugePage

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, daveg <daveg(at)sonic(dot)net>, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PostgreSQL and HugePage
Date: 2010-10-20 19:17:27
Message-ID: AANLkTikur--tTbD68aguYBzsWKjmvvUCdCOz5JFwN+Sy@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Oct 20, 2010 at 7:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I believe that for the equivalent Solaris option, we just automatically
> enable it when available.  So there'd be no need for user documentation.
> However, I definitely *would* like to see some benchmarks proving that
> the change actually does something useful.  I've always harbored the
> suspicion that this is just a knob to satisfy people who need knobs to
> frob.

Well saving a few megabytes of kernel space memory isn't a bad thing.
But I think the major effect is on forking new processes. Having to
copy that page map is a major cost when you're talking about very
large memory footprints. While machine memory has gotten larger the 4k
page size hasn't. I don't think it's a big cost once all the processes
have been forked if you're reusing them beyond perhaps slightly more
efficient cache usage.


-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-10-20 19:28:25
Subject: Re: PostgreSQL and HugePage
Previous:From: David FetterDate: 2010-10-20 19:16:52
Subject: Re: WIP: extensible enums

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group