Simon Riggs <simon@2ndQuadrant.com> wrote:
> On Thu, 2009-05-07 at 12:39 -0500, Kevin Grittner wrote:
>> Simon Riggs <simon@2ndQuadrant.com> wrote:
>>
>> > Each user must compare against work performed by all other users.
>> > O(N).
>> >
>> > There are N users, so O(N^2).
>>
>> Why does that apply here and not in the update conflict detection?
>
> I think the shoe is on the other foot. :-)
That's a question, and I think a fair one. As with update conflict
detection, you check whether there are any conflicting locks for what
you are currently accessing. For most usage patterns you won't find
conflicting access the vast majority of the time. The assertion that
there is some need for each session to wade through something for
every other session seems baseless to me. I'm wondering what I might
be missing.
If you throw a formula out there, I do think it's incumbent on you to
explain why you think it fits. If I threw a formula out there, then
it would be fair of you to ask me to explain how I got to it. I'm not
at a point where I think I can estimate performance impact. I guess I
would tend to start from the benchmarks published in the paper, some
of which were confirmed by the ACM SIGMOD repeatability committee.
Eyeballing that, it looks to me like the worst case they found was
about a 15% performance hit, with large stretches of some of the
graphs hanging within 1% of the performance of straight snapshot
isolation.
I think that given published benchmarks with confirmation from an
independent organization like ACM, it would be incumbent on anyone who
questions the benchmarks to explain why they think they're not
accurate or useful. The only concern I've seen so far has been that
these benchmarks lack long and complex database transactions, which
seems like a fair concern. Scalability with additional concurrent
sessions seems good as far as they took it, which was 50 sessions.
Even on a server with 16 CPUs backing a database with 3 million to 4
million hit per day, with tens of millions of database transactions
per day, we use a connection pool with fewer sessions than that.
-Kevin