(separating actual patch questions from future step discussions into a separate thread)
Paul J Stevens wrote: > > (BTW, how did you like my dbmysql patch? In my eyes it's one of > those > > easy optimizations, but I ceratinly won't be sure of it until I see > the > > result of an independent review :) > > I have only one major problem with your patch: you try to outsmart the > upstream api. If a seek for the next > row is so much more expensive than a simple fetch_next_row, that's > mysql's problem and should be fixed > upstream. Well, actually, the entire idea of separating mysql and pgsql code into separate files is to adapt to mysql's and pgsql's specifics, right? And "specific" does include "problems". > Also, I hate introducing new statics in the code. They are an > obfuscation, and will make it that > much harder if we want to go for a threaded process model. I thought about it too, but res and last_row are already static. last_row was not really used before my patch; but the fact that res is static, alone, means a major rewrite for a threaded model. My point here is that my patch makes the current code work much better (see Xing's independent test) while keeping it as bad as it was before; the patch code is admittedly bad, but it's at the same level of badness as the existing code. A refactoring to do away with the badness will mean doing away with this badness too. To be more specific, a refactoring for thread-safe-ness ;), given that we stay with C, would probably mean something like a "context" to store every connection in. The caller would pass the "context" to every database-specific function. And this "context" would include my new statics as well as the existing statics. Yours, Mikhail Ramendik
