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, and one reason
why I dislike Microsoft is that their software does exactly that.
Messing with the optimizer might result in bad plans, much to
the surprise of the user who "changed nothing". What have you won
if you take out fewer locks, but your query runs forever?
I'd opt for good documentation that tells you about the pitfalls
of this serializable implementation and counsels you. That also helps
to keep it simple.
Yours,
Laurenz Albe