Greg Stark <gsstark@mit.edu> wrote:
> On Thu, Jan 7, 2010 at 8:43 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> No, it's an attempt to reflect the difference in costs for true
>> serializable transactions, so that the optimizer can choose a
>> plan appropriate for that mode, versus some other. In
>> serializable transaction isolation there is a higher cost per
>> tuple read, both directly in locking and indirectly in increased
>> rollbacks; so why lie to the optimizer about it and say it's the
>> same?
>
> This depends how you represent the predicates. If you represent
> the predicate by indicating that you might have read any record in
> the table -- i.e. a full table lock then you would have very low
> overhead per-tuple read, effectively 0. The chances of a
> serialization failure would go up but I don't see how to represent
> that as a planner cost.
>
> But this isn't directly related to the plan in any case. You could
> do a full table scan but record in the predicate lock that you
> were only interested in records with certain constraints. Or you
> could do an index scan but decide to represent the predicate lock
> as a full table lock anyways.
All valid points. I could try to make counter-arguments, but in my
view the only thing that really matters is how any such attempt
performs in a realistic workload. If, when we get to the
optimization phase, such a technique shows a performance improvement
in benchmarks which we believe realistically model workloads we
believe to be reasonable candidates to use serializable
transactions, then I'll argue that the burden of proof is on anyone
who thinks it's a bad idea in spite of that. If it doesn't show an
improvement, I'll be the first to either try to refine it or toss
it. Fair enough?
-Kevin