I wrote: > Greg Stark <st...@enterprisedb.com> wrote: >> This thread has really been one of those cases where everyone >> thought they were having a different kind of discussion. > > Apparently so. In light of discussions at PGCon, I'm going to abandon this thread in favor of a discussion of what this feature would look like from a user perspective. Only after there is consensus (if any) on the desirability of the behavior will I move on to a discussion of implementation techniques -- probably on a fresh thread. For the record, it became clear that I did a bad job of communicating on this thread, so I'll finish it with some clarifications and observations "just for the record." First, the paper didn't propose any new techniques for predicate locking, other than using a lock level which doesn't block anything else. It did reference existing papers on locking techniques. Second, Robert Haas had an interesting insight: if the techniques from the paper were implemented in the absence of predicate locks, that would still reduce the frequency of serialization anomalies from current snapshot isolation techniques. Since the PostgreSQL community generally prefers incremental enhancement patches on the way to a final result, he suggested that this would be a good path -- do everything except the predicate locks, show the incremental benefits, then add the predicate locks. We could probably even add the predicate locks in stages: first implement table level predicate locks, since that has to exist and would provide a complete, if somewhat clumsy, serializable solution; then move on to more fine-grained locks. It would probably be workable, and possibly optimal, to have just table and page locks; although it seems likely that index range locks and row locks would also be worth it, eventually. But all that is just to get it on the record; I'm getting ahead of myself here. I'll be posting on the user-facing aspects of this soon. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers