Greg Stark <gsstark@mit.edu> wrote:
> My comment was in relation to the idea of representing the costs
> in the planner. I was a) saying you had to see how the
> implementation went before you try to come up with how to
> represent the costs and then b) speculating (hypocritically:) that
> you might have the direction of adjustment backward.
I think we may be agreeing violently. I had the thought that
costing may need to be adjusted, suggested the easiest hack that
seemed like it might show an improvement, and said it needed more
thought before we got to trying it out in the optimization phase.
I don't think we actually disagree about much there.
> 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. :-)
-Kevin