From: | "Dario" <dario_d_s(at)unitech(dot)com(dot)ar> |
---|---|
To: | "Joe" <svn(at)freedomcircle(dot)net>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Comparative performance |
Date: | 2005-10-04 23:19:14 |
Message-ID: | MHEDJHCKDNOEHJKHIOCJIECICIAA.dario_d_s@unitech.com.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Postgresql uses MVCC to ensure data integrity. Server must choose the right
version of tuple, according to transaction ID of statement. Even for a
select (ACID features of postgresql, I think C and I apply here), it must
accomplish some extra work.
-----Mensaje original-----
De: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org]En nombre de Joe
Enviado el: martes, 04 de octubre de 2005 18:11
Para: Jim C. Nasby
CC: Andreas Pflug; pgsql-performance(at)postgresql(dot)org
Asunto: Re: [PERFORM] Comparative performance
Hi Jim,
Jim C. Nasby wrote:
> Also, just because no one else has mentioned it, remember that it's very
> easy to get MySQL into a mode where you have no data integrity. If
> that's the case it's going to be faster than PostgreSQL (though I'm not
> sure how much that affects the performance of SELECTs).
Yes indeed. When I added the REFERENCES to the schema and reran the
conversion
scripts, aside from having to reorder the table creation and loading (they
used
to be in alphabetical order), I also found a few referential integrity
errors in
the MySQL data.
Joe
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Peacetree | 2005-10-04 23:33:47 | Re: Is There Any Way .... |
Previous Message | Mark Lewis | 2005-10-04 22:23:52 | Re: Is There Any Way .... |