From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CLOG contention, part 2 |
Date: | 2012-01-27 23:16:57 |
Message-ID: | CAHyXU0wukkdwBkUSFcFUeF_H+cpa_nKJz0d3=FZ9eXzuy2r=XQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 27, 2012 at 4:05 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> Also, I think the general approach is wrong. The only reason to have
> these pages in shared memory is that we can control access to them to
> prevent write/write and read/write corruption. Since these pages are
> never written, they don't need to be in shared memory. Just read
> each page into backend-local memory as it is needed, either
> palloc/pfree each time or using a single reserved block for the
> lifetime of the session. Let the kernel worry about caching them so
> that the above mentioned reads are cheap.
right -- exactly. but why stop at one page?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tareq Aljabban | 2012-01-27 23:37:38 | Re: Configuring Postgres to Add A New Source File |
Previous Message | Adrian Klaver | 2012-01-27 23:11:32 | Re: pg_dump -s dumps data?! |