RE: Protect syscache from bloating with negative cache entries

From: Robert Haas [mailto:robertmhaas(at)gmail(dot)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 time only 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 in a later mail in response to Horiguchi-san.

Regards
Takayuki Tsunakawa