Greg Stark <gsstark(at)mit(dot)edu> wrote:
> Well we disagree with whether we have any reasonable plan for
> adding the more fine-grained locks.
We probably agree on that, too. Perhaps it's that I think we can
develop one within a few months and you don't?
> 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.
Well, I sure hope we can avoid falling into either of those pits.
It sounds like Robert has some ideas on a clean approach. I haven't
looked at that aspect deeply enough to make detailed suggestions.
> 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.
I don't plan to throw any of that away; all existing techniques will
continue to be used for all transactions, and unless a transaction
is serializable it will not use any new techniques. For a
serializable transaction the granularity of information used to
detect dangerous structures will need to be kept in RAM and will
therefore need to support coarser granularity at times to avoid
running out of space. Coarser granularities will cause a higher
rollback rate for serializable transactions. The optimization phase
is mostly about minimizing "false positive" rollbacks. We probably
have different thresholds for how many serialization errors we'd be
willing to tolerate to get the benefits of true serializability, but
that doesn't seem like a very fundamental difference to me.
-Kevin