Simon Riggs <si...@2ndquadrant.com> wrote: > On Thu, 2009-05-07 at 12:39 -0500, Kevin Grittner wrote: >> Simon Riggs <si...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers