On Sun, September 3, 2006 23:28, Jeroen T. Vermeulen wrote:
> On Sun, September 3, 2006 21:52, Gregory Stark wrote:
>> I read that but apparently I misunderstood it since it would not have
>> been
>> doable the way I understood it. I thought you wanted the predictor bits
>> to
>> correspond to particular plans. If a plan was "wrong" then you marked it
>> as a
>> bad guess. I don't think that can be made to work though for the reasons
>> I
>> stated then.
Come to think of it, I still haven't answered your question very clearly...
I keep one predictor for any given statement. The predictor keeps two
pieces of state *per statement parameter*:
1. The predictor value (usually the last-seen value for that parameter,
though it does take a few mismatches to make it drop a value that was
repeated a lot).
2. A saturating counter measuring confidence in the current predictor
value. As long as this counter is below the confidence threshold, the
predictor value has no other meaning than "let's see if this value comes
back."
No information flows between these pieces of state. All logic in the
predictor itself is entirely local to individual parameters. But any new
plan is generated based on a "snapshot" of all predictor values that (i)
match their respective parameter values in the ongoing call, and (ii) have
their counters above the confidence threshold. It is that combination of
parameters, for that combination of values, that is taken as a set of
pseudo-constants.
The cache can hold any number of plans optimized for the same combinations
of parameters but with different values; or for different combinations of
parameters but the same values; subsets and supersets of parameters with
either the same or different values; completely disjoint sets; anything.
The cache neither knows nor cares. The only thing that *won't* happen is
two plans in the same cache covering the same set of parameters with the
same set of values--because there is never any need to generate that
second plan while the first is still in cache.
Jeroen
