RE: Protect syscache from bloating with negative cache entries

From: Robert Haas [mailto:robertmhaas@gmail.com]
> I don't understand the idea that we would add something to PostgreSQL
> without proving that it has value.  Sure, other systems have somewhat
> similar systems, and they have knobs to tune them.  But, first, we
> don't know that those other systems made all the right decisions, and
> second, even they are, that doesn't mean that we'll derive similar
> benefits in a system with a completely different code base and many
> other internal differences.

I understand that general idea.  So, I don't have an idea why the proposed approach, eviction based only on elapsed
timeonly at hash table expansion, is better for PostgreSQL's code base and other internal differences...
 


> You need to demonstrate that each and every GUC you propose to add has
> a real, measurable benefit in some plausible scenario.  You can't just
> argue that other people have something kinda like this so we should
> have it too.  Or, well, you can argue that, but if you do, then -1
> from me.

The benefit of the size limit are:
* Controllable and predictable memory usage.  The DBA can be sure that OOM won't happen.
* Smoothed (non-abnormal) transaction response time.  This is due to the elimination of bulk eviction of cache
entries.


I'm not sure how to tune catalog_cache_prune_min_age and catalog_cache_memory_target.  Let me pick up a test scenario
ina later mail in response to Horiguchi-san.
 


Regards
Takayuki Tsunakawa