On Wed, Dec 21, 2011 at 3:24 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers