From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Andy Colson <andy(at)squeakycode(dot)net> |
Cc: | Corin <wakathane(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: mysql to postgresql, performance questions |
Date: | 2010-03-21 22:43:06 |
Message-ID: | b42b73151003211543w764cfb9bwe3666671310b875a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, Mar 20, 2010 at 11:47 PM, Andy Colson <andy(at)squeakycode(dot)net> wrote:
> Don't underestimate mysql. It was written to be fast. But you have to
> understand the underling points: It was written to be fast at the cost of
> other things... like concurrent access, and data integrity. If you want to
> just read from a database, PG probably cant beat mysql. But heres the
> thing, your site does not just read. Nor does it fire off the same sql 10
> times. So not a good test.
for non trivial selects (myisam has no transaction overhead so can
usually edge out pg in row by row ops), and without taking multi user
issues into account, it's often going to come down to who generates a
better plan. postgres has more plan options and a better statistics
model and can usually beat mysql on many types of selects.
updates w/myisam are where mysql really shines in single user apps.
the reason is obvious: no mvcc means the heap can often be updated in
place.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Crooke | 2010-03-22 01:14:19 | Re: mysql to postgresql, performance questions |
Previous Message | Bob Lunney | 2010-03-21 18:03:30 | Re: pg_dump far too slow |