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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers