Re: PostgreSQL and HugePage - Mailing list pgsql-hackers

From Greg Stark
Subject Re: PostgreSQL and HugePage
Date
Msg-id AANLkTikur--tTbD68aguYBzsWKjmvvUCdCOz5JFwN+Sy@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL and HugePage  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PostgreSQL and HugePage
List pgsql-hackers
On Wed, Oct 20, 2010 at 7:10 AM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: WIP: extensible enums
Next
From: Robert Haas
Date:
Subject: Re: pg_upgrade patch application process, and move to /bin?