Re: testing HS/SR - 1 vs 2 performance
От | Simon Riggs |
---|---|
Тема | Re: testing HS/SR - 1 vs 2 performance |
Дата | |
Msg-id | 1272214858.4161.1819.camel@ebony обсуждение исходный текст |
Ответ на | Re: testing HS/SR - 1 vs 2 performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: testing HS/SR - 1 vs 2 performance
|
Список | pgsql-hackers |
On Sun, 2010-04-25 at 12:51 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Sun, 2010-04-25 at 11:50 -0400, Tom Lane wrote: > >> This needs a redesign before it can be considered committable. I don't > >> really care whether it makes things faster; it's too complicated and too > >> poorly documented to be maintainable. > > > There are more than 60 lines of header comment explaining in detail how > > this works, with a full algorithmic analysis. The remaining code is > > commented to project standards, with easily more than 100 lines of > > comments. > > If the comments were correct, I wouldn't be complaining. They're > misleading or outright wrong on many points. In particular, I don't > think you actually understand the weak-memory-ordering issue, because > the comments about that are entirely wrong. The comments says "on CPUs with + * weak-memory ordering we can't reliably move pointers atomically, so the + * rule is that updates of head and tail of the array require ProcArrayLock + * in exclusive mode or (shared mode and known_assigned_xids_lck spinlock)" I will reword this, so it is clear that I'm talking about the head and tail of the array, not pointers in general. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: