On Oct 20, 2010, at 7:44 PM, Gabi Julien wrote:

> Hi,
> 
> Here is my problem: I have a postgresql C function that looks like this:
> 
> Datum filter(PG_FUNCTION_ARGS);
> 
> It takes identifiers and queries a bunch of tables and ends up returning true 
> or false. So far nothing difficult except that we want better performance. 
> The function was already optimized to the best of my abilities and changing 
> the structure of the database would not help. However, having a cache would 
> be the perfect solution. I could implement this cache outside of postgresql 
> if need be but nothing could beat implementing this directly in a postgresql 
> C function.
> 
> So this is what I want, a custom cache built into a postgresql C function. 
> Since postgresql uses different processes, it would be best to use the shared 
> memory. Can this be done safely? At its core, the cache could be considered 
> as simple as a map protected by a mutex. With postgresql, I first need to 
> initialized some shared memory. This is explained at the end of this link:
> 
> http://www.postgresql.org/docs/8.2/static/xfunc-c.html
> 
> However, it sounds like I need to reserve the shared memory in advance using:
> 
> void RequestAddinShmemSpace(int size)
> 
> In my case, I do not know how big my cache will be. I would preferably 
> allocate the memory dynamically. Is this possible? In any case, am I trying 
> to reinvent the wheel here? Is there already a shared map or a shared hash 
> structure available in postgresql?
> 
> If shared memory turns out too difficult to use, I could create separate 
> caches for each postgresql processes. This would be a waste of space but it 
> might be better then nothing. In this case, do I need to make my code thread 
> safe? In other words, is postgresql using more then one thread per processes?

Apart from the other suggestions made, another option could be to use your own 
shared memory which you allocate and manage yourself (without postgresql 
managing it). You could implement a simple least-recently-used cache to purge 
old entries as the cache grows.

Cheers,
M
-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to