RE: Protect syscache from bloating with negative cache entries - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Protect syscache from bloating with negative cache entries
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB9ECBC@G01JPEXMBYT05
Whole thread Raw
In response to Re: Protect syscache from bloating with negative cache entries  (Robert Haas <robertmhaas@gmail.com>)
Responses RE: Protect syscache from bloating with negative cache entries
Re: Protect syscache from bloating with negative cache entries
List pgsql-hackers
From: Robert Haas [mailto:robertmhaas@gmail.com]
> That might be enough to justify having the parameter.  But I'm not 
> quite sure how high the value would need to be set to actually get the 
> benefit in a case like that, or what happens if you set it to a value 
> that's not quite high enough.  I think it might be good to play around 
> some more with cases like this, just to get a feeling for how much 
> time you can save in exchange for how much memory.

Why don't we consider this just like the database cache and other DBMS's dictionary caches?  That is,

* If you want to avoid infinite memory bloat, set the upper limit on size.

* To find a better limit, check the hit ratio with the statistics view (based on Horiguchi-san's original 0004 patch,
althoughthat seems modification anyway)
 


Why do people try to get away from a familiar idea...  Am I missing something?

Ideriha-san,
Could you try simplifying the v15 patch set to see how simple the code would look or not?  That is:

* 0001: add dlist_push_tail() ... as is
* 0002: memory accounting, with correction based on feedback
* 0003: merge the original 0003 and 0005, with correction based on feedback


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Vectors instead of lists, specialised qsort(), binary_search(), unique()
Next
From: "Nagaura, Ryohei"
Date:
Subject: RE: Timeout parameters