Re: Reducing overhead of frequent table locks
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alexey Klyukin <alexk@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-05-25T15:47:31Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix possible "tuple concurrently updated" error in ALTER TABLE.
- fbcf4b92aa64 9.1.0 cited
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. +