Re: CLOG contention

On Wed, Dec 21, 2011 at 3:24 PM, Robert Haas <robertmhaas(at)gmail(dot)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