Alvaro Herrera wrote:
> So I think this is the only remaining issue to make this patch
> committable (I will address the other points in Andres' email.) Since
> there has been no other feedback on this thread, Andres and I discussed
> the cache issue a bit over IM and we seem to agree that a patch to
> revamp the cache should be a fairly localized change that could be
> applied on both 9.3 and master, separately from this fix. Doing cache
> deletion seems more invasive, and not provide better performance anyway.
Here's cache code with LRU superpowers (ahem.)
I settled on 256 as number of entries because it's in the same ballpark
as MaxHeapTuplesPerPage which seems a reasonable guideline to follow.
I considered the idea of avoiding palloc/pfree for cache entries
entirely, instead storing them in a static array which is referenced
from the dlist; unfortunately that doesn't work because each cache entry
is variable size, depending on number of members. We could try to work
around that and allocate a large shared array for members, but that
starts to smell of over-engineering, so I punted.
I was going to 'perf' this, but then found out that I need to compile my
own linux-tools package for a home-compiled kernel ATM.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services