Re: Best database for web backend on Linux?

Evan Carew wrote: > David Williams wrote: > >> >Glad to hear it! I'll bet you tho if it were not dependant on RLL >> (sorry but >> >I'm getting tired of typing row level locking all the time) one if >> not both of >> >the following would happen: >> >1. The cost of hardware for supporting the application would go >> down due to >> >lower resource usage >> >> What you mean 1Mb of memory to hold lock info costs a vast amout >> of >> money (Inofmrix lock =43 bytes, just how many locks do you need?) >> >> >2. The capacity and performance of your already zipy application >> would increace >> >noticably. >> > >> >> What with people wait for locks on data rows they are not even >> touching?? How can that be faster?? > > I'm not shure, but I think we have a language problem here. What I was > suggesting was all that IO and ancellary CPU time spent managing RLL > would go away and thus improve your performance/capacity. What he's suggesting is that there should be no added I/O and the ancillary CPU time should be minimal if not actually non-existent. > If I understand your argument correctly, what you are saying is that you are willing to pay less for development now (presumably because your design simply isn't acceptable without RLL) and ignore the potiential cost of capacity/performance based upgrades later. > I think what he's saying is that it is unlikely he will have to upgrade his hardware simply because he requires an extra 43 bytes of memory for each row lock. I'd suggest that your apparent disconnect is that you are arguing Sybase vs. Oracle, and, based on what you have said of Oracle's locking (I'll have to take your word for it, as I know very little about Oracle), your arguments are sound. However, he is talking about Informix, which requires no I/O to do locking, and not any significant amount more CPU to lock a row than a page (or even to lock several rows, vs. locking a page). Therefore, any arguments for using PLL because of faster performance do not apply. On the other hand, concurrency issues are still a factor. You are talking about trade-offs: performance vs. concurrency. He is saying there is no loss of performance for the improved concurrency. June -- june_t@hotmail.com Grounded in Palo Alto, living on M&M's (peanut)