On Wed, Dec 21, 2011 at 3:24 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think there probably are some scalability limits to the current
> implementation, but also I think we could probably increase the
> current value modestly with something less than a total rewrite.
> Linearly scanning the slot array won't scale indefinitely, but I think
> it will scale to more than 8 elements. The performance results I
> posted previously make it clear that 8 -> 32 is a net win at least on
> that system.
Agreed to that, but I don't think its nearly enough.
> One fairly low-impact option might be to make the cache
> less than fully associative - e.g. given N buffers, a page with pageno
> % 4 == X is only allowed to be in a slot numbered between (N/4)*X and
> (N/4)*(X+1)-1. That likely would be counterproductive at N = 8 but
> might be OK at larger values.
Which is pretty much the same as saying, yes, lets partition the clog
as I suggested, but by a different route.
> We could also switch to using a hash
> table but that seems awfully heavy-weight.
Which is a re-write of SLRU ground up and inapproriate for most SLRU
usage. We'd get partitioning "for free" as long as we re-write.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
