Re: Tuning/performance issue...
От | Jeff |
---|---|
Тема | Re: Tuning/performance issue... |
Дата | |
Msg-id | Pine.BSF.4.44.0310040852300.41997-100000@torgo.978.org обсуждение исходный текст |
Ответ на | Re: Tuning/performance issue... (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-performance |
On Fri, 3 Oct 2003, Bruce Momjian wrote: > > I have updated the FAQ to be: > > In comparison to MySQL or leaner database systems, we are > faster for multiple users, complex queries, and a read/write query > load. MySQL is faster for SELECT queries done by a few users. > > Is this accurate? It seems so. > > Another thing I noticed - If you use a dataset that can live in mysql's query cache / os cache it screams, until it has to hit the disk. then GRINDING HALT. It would be nice if someone (I don't have the time now) did a comparison of say: selct value where name = XXX; [where xxx varies] with 1,10,20,50 connections then make progressively more complex queries. And occasionally point out mysql silly omissions: select * from myview where id = 1234 [Oh wait! mysql doesn't have views. Ooopsy!] Wrapping up - PG is not that slow for simple queries either. It can be rather zippy - and PREPARE can give HUGE gains - even for simple statements. I've often wondered if YACC, etc is a bottleneck (You can only go as fast as your parser can go). Hurray for PG! And I'm giving my PG presentation monday. I hope to post it tuesday after I update with comments I receive and remove confidential information. -- Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/ http://www.stuarthamm.net/
В списке pgsql-performance по дате отправления: