On Fri, Jan 8, 2010 at 5:13 PM, Kevin Grittner
<Kevin.Grittner@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