Re: RE: [GENERAL] PHPBuilder article -- Postgres vs MySQL
От | Don Baccus |
---|---|
Тема | Re: RE: [GENERAL] PHPBuilder article -- Postgres vs MySQL |
Дата | |
Msg-id | 3.0.1.32.20001120204835.021e9490@mail.pacifier.com обсуждение исходный текст |
Ответ на | RE: [GENERAL] PHPBuilder article -- Postgres vs MySQL ("Robert D. Nelson" <RDNELSON@co.centre.pa.us>) |
Список | pgsql-hackers |
At 11:22 AM 11/13/00 -0500, Robert D. Nelson wrote: >Still...Regardless of what database they're running, either their >abstraction layer is shit or their queries really need optimized. Is that >perhaps why, even at 5 clients, the page views he shows never went >significantly above 10/sec? They don't appear to do any client-side query caching, which is understandable from one point of view (you need some sort of handle on which queries are hit frequently enough to warrant devoting RAM to caching the result, or else you risk caching things that don't gain you much and cut down on the amount of the DB cached in RAM which hits you on other queries). On the other hand, you'd think they'd do some analysis... Still, the table-locking of MySQL just gets in the way. If you can cache everything, then you can send a postal worker to the mailbox to retrieve uncached data without significantly impacting throughput (in other words, the MySQL argument that simple select benchmarks are all you need are not relevant). If you can't cache anything but have few users, then perhaps low levels of concurrency don't hurt. If you don't cache anything but have lots of users, scaling well under high levels of load rule. My thinking is that intellegent caching coupled with a highly-scalable database wins. That's the world I'm used to... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: