On 7/9/2010 12:50 PM, Nikunj Mehta wrote:
Dynamic scope == dynamic transactions, correct? Can you please elaborate on how dynamic transactions improve performance?The point is that we are talking of leaving out dynamic scope in v1, while, in the same vein, talking of making READ_ONLY the default _because_ it produces "good" performance. That is, IMHO, contradictory.
FWIW, this isn't constructive. Your argument also seems to assume that writes are more common than reads, which hasn't been my experience with this API.This seems to be conveniently justified. A strict interpretation of the objective would not require the programmer to specify READ_WRITE even though that involves less mental (cognitive) and physical (typing) effort.
Why make writing code with good performance characteristics the uncommon case? We clearly have two different schools of thoughts here, and I'm not sure we are going to find a consensus...It should have worked right the first time. Why wait for a programmer to find out why their code didn't work?
It's unclear to me why you think READ_ONLY is getting special treatment (or what that even means in this context).There are many ways to get performance improvement, including dynamic transactions, which you seem not to be favorable towards. I don't see why READ_ONLY should be given special treatment.
While I think this argument makes sense in some cases, I really don't feel like it applies at all in this situation. Even the page you linked to says "Because the SQL Server query optimizer typically selects the best execution plan for a query..." which in most cases would be READ_ONLY (based on evidence the Mozilla team has from demos written). The default should represent the commonly used case.Various hints are used in SQL syntax, e.g., [1], to manage locks, a certain kind of B-tree behavior, or a level of isolation. These are all aimed at improving performance, but they are set as default behavior. My point is that expecting good performance from a single variable in database systems out of possibly hundreds is not all that helpful. It is also a slippery slope because it confuses performance with options. The database's job is to be fast at what it does, not play performance tricks using default values.
I don't know that we can make the right performance decisions for people. What we can do is make things perform well and provide tools to improve performance.We aren't making performance decisions though; we are just picking the default to be the most commonly used option. It just happens to be the one to allow more concurrency.
Cheers, Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
