Re: Tuning/performance issue... - Mailing list pgsql-performance

From Jeff
Subject Re: Tuning/performance issue...
Date
Msg-id Pine.BSF.4.44.0310040852300.41997-100000@torgo.978.org
Whole thread Raw
In response to Re: Tuning/performance issue...  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: count(*) slow on large tables
Next
From: Andrew Sullivan
Date:
Subject: Re: reindex/vacuum locking/performance?