Horton

Re: [v9.1] sepgsql - userspace access vector cache

Kohei Kaigai <kohei.kaigai@emea.nec.com>

View thread
From: Kohei Kaigai <Kohei.Kaigai@EMEA.NEC.COM>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Yeb Havinga <yebhavinga@gmail.com>, Kohei KaiGai <kaigai@kaigai.gr.jp>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2011-07-20T17:00:30Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove the limit on the number of entries allowed in catcaches, and

> On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
> <Kohei.Kaigai@emea.nec.com> wrote:
> > One question is why InitCatalogCache() should be invoked from InitPostgres()?
> > If we initialize syscache on starting up postmaster process, I think
> > all the syscache buckets will be ready on child process forks, and
> > unused syscache does not consume physical memory, even if security
> > label acquire 2048 of buckets.
> 
> Most of the overhead seems to be the cost of the page faults required
> for the kernel to map the relevant pages into the process address
> space.  After a fork(), all those pages become copy-on-write, so if
> the syscaches are actually used this doesn't save much of anything.
> In the specific case of sepgsql it would help, though, because what
> you're proposing is to add a syscache that will in most cases never be
> accessed at all.  We'd still have a problem in the EXEC_BACKEND (i.e.
> Windows) case, however...
> 
Hmm. It might not work in windows case.

I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
 - Initial bucket allocation on most cases never be referenced.
 - Reclaim cache entries on growing up too large.

Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kaigai@emea.nec.com>