On Thu, 2005-02-17 at 10:00, Aaron Stone wrote: > On Thu, Feb 17, 2005, Hans Kristian Rosbach <[EMAIL PROTECTED]> said: > > >> Off the cuff, I would take it to be that one UPDATE is faster than one > >> SELECT, but only up to a certain concurrency rate, after which the > >> non-locking SELECT is faster. Yes, no? Are there some statistics we can > >> put to this? > > > > In any case an update cannot be cached, an select can. > > But the select has a function in it, and necessarily only runs while the > database is being written to, so the cache is likely to be expired.
I also came to think about clustering. In those an update is very expensive compared to selects. But an option would be ok for cluster users. > >> This smacks of needing a configuration option so that a site can use the > >> method best for their own usage pattern. > > > > As long as the defaults are sane enough for the average joe, not just > > us expert users. > > Where Mr. Expert is much more likely to be running a large site than Joe > is, and therefore should be comfortable tuning things to work on such a > site. Yup. -HK
