On 25 Nov 2012, at 11:30pm, "Jay A. Kreibich" <j...@kreibi.ch> wrote:
> If you view an index as an optimization, then the idea > is usually to increase overall performance, so that there is net win. [snip] > > I disagree with this idea, as it implies there is a 1:1 exchange in > read performance gains and write performance loss. To enlarge upon Jay's monotribe, I'll put these two together. Optimization of a system sometimes doesn't mean optimizing /net/ performance, it means speeding things up when time matters. I once got an ovation from a roomfull of staff by deleting a couple of indexes, not adding them. Because they spent most of their time entering data, but reports were generated by other people they never met and didn't care about. My changes reduced a two-second pause after hitting 'send' to half a second, massively reducing false keystrokes. The report-needing people, on the other hand didn't care. It already took the system 30 minutes to generate the reports: they pressed the button and came back an hour later. Changing the 30 minutes to 50 minutes didn't impact their workflow badly. Out of courtesy I explained why the end-of-day reports were taking longer and nobody complained. (By the way this sort of thing is why banks used to close to customers at 3:30pm even though the staff still worked until 5pm.) This was decades ago on a pre-SQL system. One thing I like about SQL is that the language used to change and consult the database doesn't say anything about indexes (except in some non-standard extensions). So you can add or delete indexes when you want without needing to change a line of code in any of your software and having to deploy new versions of your software. [insert dramatic evil genius music here] Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
