Pavel, jim et al,

> From my POV, the GC thread is poorly designed - badly chosen
> trade off.
> Transaction may win a spared page write _only_ when row is
> accessed for
> read, but for significantly bigger chance that chain would
> span to other
> pages so next transactions would be hit not just chain traversal, but
> also by more page reads. At the end, all users that would
> access the row
> are hit harder than one poor reader that would get nailed to GC.

I suspect that the real performance problem lies in the implementation
of the page list (management) code. I also wonder if the GC is
affecting the current cache pages as it cleans up, that is to say that
the GC is clearing the page cache of necessary pages as a result of
loading/GCing the pages.

I'm not so sure that the design/idea of the GC thread is such a bad
idea. It seems reasonable that the server idle time should be used to
perform and valuable task -- clean pages is a 'good thing', in favour of
improving the speed or readers and writers.

The problem obviously comes when the server is so busy that the idle
time is limited and the list of dirty pages gets bigger and bigger.

> Although it would be nice to implement the approach used in
> Netfrastructure, I don't see it doable right now (after all, we still
> haven't a resolution for CS vs. SS war :).

Yep, that battle is still "a waging", there a lull in the battle as the
camps (the young pups and the Old Wolf) regroup for the next assault.

Back to the Netfrastructure model -- it is very cool. Although, since
Jim explained to me (one night over some drinks), I have wondered if
that approach (in MGA memory only) would run into problems when the
amount of changes was larger than available RAM/memory, but I'm sure
that Jim had already taken that into account.


Sean