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: | 10919.1139156199@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
SQL.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Hills | 2006-02-05 17:13:29 | Re: Shared memory and memory context question |
Previous Message | Andrew Dunstan | 2006-02-05 16:15:42 | Re: drop if exists remainder |