Jeff Davis <pg...@j-davis.com> wrote: > Is a full table lock acceptable in the end? If so, then predicate > locking is just optimization, and we should leave it until later. I think that the predicate locking will need to be RAM-based to provide acceptable performance, and that we will need a multi-granularity approach with granularity promotion which will include table locks in some situations. > If not, then reasonably efficient predicate locking is a part of > the design. We can still leave it until later, but we shouldn't > call design issues "premature optimization". Well, technically table locking can be used to provide predicate locking; it is just way too coarse-grained to be acceptable for production as the *only* technique. The optimization phase will involve many types of optimization, but a lot of it will be balancing the overhead of finer-grained locks against the higher rate of false positives with coarser-grained locks. I really think that the correct way to view this is to view backing off to finer-grained resolutions as optimization, albeit absolutely necessary optimization. I totally understand the impulse to work on these details up front -- I'm fighting against such an impulse myself. I've just convinced myself, rationally, that such work is better deferred. On the other hand, perhaps if I'm working the development path in the wiki page, it *could* make sense, if you're interested, to look at issues like this now and get them all documented and ready to go once I get far enough along -- we could "meet in the middle." Another interesting thing which crossed my mind (and I should probably add a section for such things in the wiki) is that, given the overhead and conflict implications of using table scans in serializable transactions, we should perhaps try to discourage table scans from being chosen for those using serializable transactions. I figure we can probably fudge this to a workable degree by adjusting tuple cost GUCs, but if you wanted to think about this issue in more depth, it might be useful. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
