Jeff Davis <pgsql@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
