On Sun, Dec 27, 2009 at 3:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> If we're really doing it, sure. But putting half of it in
>> TopMemoryContext and the other half in CacheMemoryContext is not
>> obviously of any value.
>
> There isn't any of that stuff that's *in* TopMemoryContext. Whet
Robert Haas writes:
> If we're really doing it, sure. But putting half of it in
> TopMemoryContext and the other half in CacheMemoryContext is not
> obviously of any value.
There isn't any of that stuff that's *in* TopMemoryContext. Whether the
hash table contexts are children of TopMemoryConte
On Sun, Dec 27, 2009 at 2:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> it does make me wonder whether there's any point in retaining
>> CacheMemoryContext at all.
>
> Well, as per backend/utils/mmgr/README:
>
> CacheMemoryContext --- permanent storage for relcache, catcache, and
> related mo
Robert Haas writes:
> it does make me wonder whether there's any point in retaining
> CacheMemoryContext at all.
Well, as per backend/utils/mmgr/README:
CacheMemoryContext --- permanent storage for relcache, catcache, and
related modules. This will never be reset or deleted, either, so it's
On Sun, Dec 27, 2009 at 12:59 PM, Tom Lane wrote:
> My inclination is to leave the actual memory allocation behavior alone
> and just get rid of the CreateCacheMemoryContext calls in these places.
I don't have a strong feeling on it. It is only one extra line of
code to make the hash table conte
Robert Haas writes:
> I was just taking a look at find_oper_cache_entry() and noticed
> something odd. When we discover that OprCacheHash == NULL, we make
> sure that CacheMemoryContext is initialized before calling
> hash_create(). But since we don't pass HASH_CONTEXT to hash_create(),
> ISTM i