Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

On Fri, Jun 1, 2012 at 5:57 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> My proposed algorithm could be made to use exactly that criterion
> by tracking a little bit more state. We'd have to tag queue entries
> with a flag indicating whether they are
>
>  Unpinned (COLD)
>
>  Pinned, and unpinning should be delayed (HOT)
>
>  Waiting to be unpinned (LUKEWARM)

This sounds awfully similar to the LIRS/CLOCK-Pro cache replacement
algorithms. They manage buffers by reuse distance based on last two
accesses. Because both algorithms demonstrate very good performance
over a wide range of cache sizes and workloads, it might be worth
exploring how they could be applicable here.

On the other hand, I agree with Merlin that searching the local queue
for every pin could be too heavy. Roberts approach amounts to
categorizing some buffers to be so hot that we basically lift them out
of the regular replacement algorithm management and don't even bother
tracking their usage on the account that it will be cheaper to figure
out their usage state after the fact. This might have some interesting
interactions with replacement algorithms that naturally keep separate
tiers of buffers. I think I'm going to try to see where that train of
thought takes me.

Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de