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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-20 19:28:25 | Re: pg_upgrade patch application process, and move to /bin? |
Previous Message | David Fetter | 2010-10-20 19:16:52 | Re: WIP: extensible enums |