Greg Stark <gsst...@mit.edu> wrote: > Well we disagree with whether we have any reasonable plan for > adding the more fine-grained locks. We probably agree on that, too. Perhaps it's that I think we can develop one within a few months and you don't? > AFAICT we have either a) add something clean and abstract which > doesn't scale at all or b) turn Postgres into a clone of Sybase by > adding something grotty with hooks all over the tree which exposes > internal details as user-visible behaviour. Well, I sure hope we can avoid falling into either of those pits. It sounds like Robert has some ideas on a clean approach. I haven't looked at that aspect deeply enough to make detailed suggestions. > The SIREAD stuff sounds cool but it's all based on these read > locks that we have no plausible implementation which doesn't throw > away all the wonderful things about Postges like that it does > everything at the tuple level and doesn't have arbitrary limits on > the size of transactions. I don't plan to throw any of that away; all existing techniques will continue to be used for all transactions, and unless a transaction is serializable it will not use any new techniques. For a serializable transaction the granularity of information used to detect dangerous structures will need to be kept in RAM and will therefore need to support coarser granularity at times to avoid running out of space. Coarser granularities will cause a higher rollback rate for serializable transactions. The optimization phase is mostly about minimizing "false positive" rollbacks. We probably have different thresholds for how many serialization errors we'd be willing to tolerate to get the benefits of true serializability, but that doesn't seem like a very fundamental difference to me. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
