On Thu, Jan 7, 2010 at 8:43 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > 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?
This depends how you represent the predicates. If you represent the predicate by indicating that you might have read any record in the table -- i.e. a full table lock then you would have very low overhead per-tuple read, effectively 0. The chances of a serialization failure would go up but I don't see how to represent that as a planner cost. But this isn't directly related to the plan in any case. You could do a full table scan but record in the predicate lock that you were only interested in records with certain constraints. Or you could do an index scan but decide to represent the predicate lock as a full table lock anyways. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers