"Albe Laurenz" <laurenz.albe@wien.gv.at> wrote:
> Kevin Grittner wrote:
>> Another interesting thing which crossed my mind (and I should
>> probably add a section for such things in the wiki) is that,
>> given the overhead and conflict implications of using table scans
>> in serializable transactions, we should perhaps try to discourage
>> table scans from being chosen for those using serializable
>> transactions. I figure we can probably fudge this to a workable
>> degree by adjusting tuple cost GUCs, but if you wanted to think
>> about this issue in more depth, it might be useful.
>
> I don't know if that's a good idea.
> It's an attempt to guess what the user really wanted,
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?
> Messing with the optimizer might result in bad plans, much to
> the surprise of the user who "changed nothing".
The transaction isolation level *is* something, and it's something
which people should expect to affect performance.
> What have you won if you take out fewer locks, but your query runs
> forever?
Well, if the load runs worse with an optimization, it's not one we
should use. As I've mentioned before, I want to get to where it's
working correctly (if slowly), and *then* start working on
optimizations (such as this one), testing each against various
workloads to determine effect.
Please note that I threw this out "for the record" as a possible
optimization to consider down the road when we hit the optimization
phase. I hope we don't have to debate every such notation in a
vacuum before we get to that phase. To forestall that in the future,
perhaps I should keep these just to the wiki and off the list. Or
would people rather see the bread crumbs drop?
> I'd opt for good documentation that tells you about the pitfalls
> of this serializable implementation and counsels you.
It's a given that we need that.
> That also helps to keep it simple.
Ignoring optimizations might keep it simple, but might not allow it
to become usable.
-Kevin