Re: Shared memory and memory context question
От | Tom Lane |
---|---|
Тема | Re: Shared memory and memory context question |
Дата | |
Msg-id | 10919.1139156199@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Shared memory and memory context question (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Shared memory and memory context question
|
Список | pgsql-hackers |
Martijn van Oosterhout <kleptog@svana.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
В списке pgsql-hackers по дате отправления: