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

Re: Shared memory and memory context question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: richard(dot)hills(at)balliol(dot)oxford(dot)ac(dot)uk, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Shared memory and memory context question
Date: 2006-02-05 16:16:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> So what you load are the already processed rules? In that case you
> could probably use the buffer management system. Ask it to load the
> blocks and they'll be in the buffer cache. As long as you have the
> buffer pinned they'll stay there.

... until you get to the end of the transaction, where the buffer
manager will barf because somebody forgot an unpin.  Long-term buffer
pins are really not acceptable anyway --- you'd essentially be asserting
that your little facility is more important than any other use of shared
buffers, and I'm sorry but that ain't so.

AFAICT the data structures you are worried about don't have any readily
predictable size, which means there is no good way to keep them in
shared memory --- we can't dynamically resize shared memory.  So I think
storing the rules in a table and loading into private memory at need is
really the only reasonable solution.  Storing them in a table has a lot
of other advantages anyway, mainly that you can manipulate them from

You can find some prior discussion of similar issues in the archives;
IIRC the idea of a shared plan cache was being kicked around for awhile
some years back.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Richard HillsDate: 2006-02-05 17:13:29
Subject: Re: Shared memory and memory context question
Previous:From: Andrew DunstanDate: 2006-02-05 16:15:42
Subject: Re: drop if exists remainder

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