Hi, Kevin Grittner wrote: > I had this flagged as needing a response, but it fell through the > cracks yesterday. Apologies for the delayed response.
No problem. > Markus Wanner <mar...@bluegap.ch> wrote: > When the Cahill paper talks about predicate locking, it *is* talking > about what to lock with SIREAD locks, at least as I read it. If you > see something to indicate otherwise, please share. (If I'm off base > on understanding any of this, I'd sure like to get straightened out > as soon as possible.) I don't remember reading about predicate locking in the paper I read. Either he didn't cover that in his first implementation (based on page level locking), or I've simply re-used that part of my in-brain-memory. > It was the way Sybase worked for ages, too. If you consider that > you're locking both the heap and index pages read, it becomes clear > that in order to add a row which conflicts with a predicate, you > have to modify a page which would have been read to check the > predicate. Hm.. interesting, thanks for this quick explanation. >> How about storing the SIREAD info in shared memory and using >> dynamic granularity based on the conflict rate and available >> memory? *duck* > > Don't duck. That's the plan. I really wish I was better at > communicating these things. :-( See lock.c and the associated > README and see if you don't think they would fit the bill. Cool! > Exactly. That's the plan. Implement it in the simplest form, then > optimize. Perfect! Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers