Mike Nolan wrote:
Seriously, I am tired of this kind of question. You gotta get bold
enough to stand up in a meeting like that, say guy's, you can ask me
how this compares to Oracle ... but if you're seriously asking me how
this compares to MySQL, call me again when you've done your homework.
Well, when I prepared my PG presentation I did some testing of MySQL (So
I could be justified in calling it lousy :). I used the latest release
(4.0.something I think)
I was first bitten by my table type being MyISAM when I thought I set
the default ot InnoDB. But I decided since my test was
script [I also decided to use this perl script for testing PG to be
fair].
For one client mysql simply screamed.
If already have test case set up, you could inform us, from where Postgres
starts to beat MySql. Because if with 5 clients it still screams then i
would give it a try in case of
On Tue, 03 Feb 2004 11:46:05 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Jeff [EMAIL PROTECTED] writes:
Not sure at what point it will topple, in my case it didn't matter
if it ran good with 5 clients as I'll always have many more clients
than 5.
I did some idle, very unscientific tests
Jeff [EMAIL PROTECTED] writes:
Not sure at what point it will topple, in my case it didn't matter if it
ran good with 5 clients as I'll always have many more clients than 5.
I did some idle, very unscientific tests the other day that indicated
that MySQL insert performance starts to suck with
Josh Berkus wrote:
Folks,
I've had requests from a couple of businesses to see results of infomal MySQL
+InnoDB vs. PostgreSQL tests.I know that we don't have the setup to do
full formal benchmarking, but surely someone in our community has gone
head-to-head on your own application?
Josh,
Wow, I didn't know that (didn't get far enough to test any rollback).
That's not a good thing. facetiousBut then again, it's MySQL who
needs rollback anyway?/facetious
On Feb 2, 2004, at 5:44 PM, Christopher Kings-Lynne wrote:
One more thing that annoyed me. If you started a process, such
On Mon, 2004-02-02 at 12:21, Josh Berkus wrote:
Folks,
I've had requests from a couple of businesses to see results of infomal MySQL
+InnoDB vs. PostgreSQL tests.I know that we don't have the setup to do
full formal benchmarking, but surely someone in our community has gone
Josh,
I evaluated MySQL + InnoDB briefly for a project, once. I didn't get
very far because of some severe limitations in MySQL.
I had to import all of the data from an existing database (MS SQL).
One of the tables was about 8 million rows, 10 fields, and had 5
indexes. I found it quite
One more thing that annoyed me. If you started a process, such as a
large DDL operation, or heaven forbid, a cartesian join (what? I never
do that!).
I believe InnoDB also has O(n) rollback time. eg. if you are rolling
back 100 million row changes, it takes a long, long time. In PostgreSQL
Seriously, I am tired of this kind of question. You gotta get bold
enough to stand up in a meeting like that, say guy's, you can ask me
how this compares to Oracle ... but if you're seriously asking me how
this compares to MySQL, call me again when you've done your homework.
Hey at least I
Um, wrong. We don't lock rows for SELECT.
No, but Chris is correct that we could do with having some kind of
shared lock facility at the row level.
Out of interest, what is it about this particular task that's so hard?
(Not that I could code it myself). But surely you can use the same sort
of
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
No, but Chris is correct that we could do with having some kind of
shared lock facility at the row level.
Out of interest, what is it about this particular task that's so hard?
Keeping track of multiple lockers in a fixed amount of disk
Out of interest, what is it about this particular task that's so hard?
Keeping track of multiple lockers in a fixed amount of disk space.
Why not look at how InnoDB does it? Or is that not applicable?
---(end of broadcast)---
TIP 3: if
Chris,
Which does a shared lock on a row as opposed to a write lock, hence
avoiding nasty foreign key deadlocks...
Um, wrong. We don't lock rows for SELECT.
Unless you meant something else? Am I not following you?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
Um, wrong. We don't lock rows for SELECT.
Unless you meant something else? Am I not following you?
I mean row level shared read lock. eg. a lock that says, you can read
but you cannot delete.
It's what postgres needs to alleviate its foreign key trigger deadlock
problems.
Chris
16 matches
Mail list logo
