Re: Reducing overhead of frequent table locks
От | Bruce Momjian |
---|---|
Тема | Re: Reducing overhead of frequent table locks |
Дата | |
Msg-id | 201105251547.p4PFlV828380@momjian.us обсуждение исходный текст |
Ответ на | Re: Reducing overhead of frequent table locks (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
Simon Riggs wrote: > On Tue, May 24, 2011 at 6:37 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > >> That being said, it's a slight extra cost for all fast-path lockers to benefit > >> the strong lockers, so I'm not prepared to guess whether it will pay off. > > > > Yeah. ?Basically this entire idea is about trying to make life easier > > for weak lockers at the expense of making it more difficult for strong > > lockers. ?I think that's a good trade-off in general, but we might > > need to wait until we have an actual implementation to judge whether > > we've turned the dial too far. > > I like this overall concept and like the way this has been described > with strong and weak locks. It seems very useful to me, since temp > tables can be skipped. That leaves shared DDL and we have done lots to > reduce the lock levels held and are looking at further reductions > also. I think even quite extensive delays are worth the trade-off. > > I'd been looking at this also, though hadn't mentioned it previously > because I found an Oracle patent that discusses dynamically turning on > and off locking. So that's something to be aware of. IMHO if we > discuss this in terms of sharing/not sharing locking information then > it is sufficient to avoid the patent. That patent also discusses the > locking state change needs to wait longer than required. FYI, I thought we had agreed not to look at any patents because looking at them might cause us more problems than not looking at them. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: