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