On Fri, Jan 8, 2010 at 5:13 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: >> From what I understand your first cut will just take full-table >> "locks" anyways so it won't matter what type of plan is used at >> all. > > Right. And it would be totally premature to try to test any > optimizations at that phase, which is reflected in the development > plan on the wiki. > >> Personally I can't see how that won't generate a serialization >> failure on basically every query on any moderately concurrent >> system but at least it would make an interesting test-bed for the >> SIREAD dependency detection logic. > > Exactly. > >> And I agree it's necessary code before we get into >> more fine-grained siread locks. > > Cool. Overall, it sounds like we've gotten to the same page. :-)
Well we disagree with whether we have any reasonable plan for adding the more fine-grained locks. AFAICT we have either a) add something clean and abstract which doesn't scale at all or b) turn Postgres into a clone of Sybase by adding something grotty with hooks all over the tree which exposes internal details as user-visible behaviour. I'm pretty unhappy with both options. The SIREAD stuff sounds cool but it's all based on these read locks that we have no plausible implementation which doesn't throw away all the wonderful things about Postges like that it does everything at the tuple level and doesn't have arbitrary limits on the size of transactions. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers