On Thu, Jan 7, 2010 at 3:43 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> "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?
I don't think this necessarily is a bad idea, but thinking that
fudging the tuple cost GUCs is going to work seems unrealistically
optimistic. If you need the optimizer to know about this, you need
the optimizer to REALLY know about this...
...Robert