Re: SSI non-serializable UPDATE performance
От | Robert Haas |
---|---|
Тема | Re: SSI non-serializable UPDATE performance |
Дата | |
Msg-id | 11386E7B-ACA8-4F3C-AA59-2DC30186A948@gmail.com обсуждение исходный текст |
Ответ на | Re: SSI non-serializable UPDATE performance (Dan Ports <drkp@csail.mit.edu>) |
Ответы |
Re: SSI non-serializable UPDATE performance
|
Список | pgsql-hackers |
On Apr 28, 2011, at 9:55 AM, Dan Ports <drkp@csail.mit.edu> wrote: > On Thu, Apr 28, 2011 at 08:43:30AM +0100, Simon Riggs wrote: >>> We added a quick return which didn't need to check any locks at the >>> front of this routine which is taken if there are no active >>> serializable transactions on the cluster at the moment of update. >> >> Surprised to hear nobody mentioning memory reordering issues about >> that, but I'm not running Itaniums anywhere. > > I did spend a while thinking about it. There aren't any memory > reordering issues with that optimization (even on the Alpha, where just > about anything goes). > > The memory barrier when acquiring the buffer page lwlock acts as the > synchronization point we need. When we see that no serializable > transactions are running, that could have been reordered, but that read > still had to come after the lock was taken. That's all we need: even if > another backend starts a serializable transaction after that, we know > it can't take any SIREAD locks on the same target while we're holding > the buffer page lock. Sounds like that might be worth a comment. ...Robert
В списке pgsql-hackers по дате отправления: