|
Home > Archive > PostgreSQL Performance > March 2006 > Re: Decide between Postgresql and Mysql (help of
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Decide between Postgresql and Mysql (help of
|
|
| Scott Marlowe 2006-03-28, 8:29 pm |
| On Tue, 2006-03-28 at 13:42, PFC wrote:
>
> Well, anybody who uses PHP and cares about performance is already using
> lighttpd, no ?
>
>
> I'll only speak about MyISAM. MySQL == MyISAM. InnoDB is useless : if you
> want transactions, use postgres.
I agree with most of what you posted, but I'm not quite sure what you
meant here.
Innodb in and of itself is a fairly decent MVCC implementation, with, as
usual, some limitations (it's rollback performance is HORRIFICLY bad).
What really makes innodb useless to me is that there's no real support
for proper operation by MySQL itself. If you could force MySQL to only
use innodb tables, and to NEVER do the wrong things syntactically, it
would be ok. But there are thousands of foot-guns in the MySQL - Innodb
combination waiting to take off your toes. Too many to count really.
To me, that's what makes innodb so useless, the way MySQL fails to
integrate well with it.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
|
|
> What really makes innodb useless to me is that there's no real support
> for proper operation by MySQL itself. If you could force MySQL to only
> use innodb tables, and to NEVER do the wrong things syntactically, it
> would be ok. But there are thousands of foot-guns in the MySQL
That's what I meant actually.
And by saying "if you want transactions" I also meant "if you want a
database system that will go to great lengths to save your XXX and your
data instead of helping you shooting yourself in the foot, generally work
very well, be reliable, friendly and a pleasure to work with, which means
more or less, if you're rational rather than masochistic, then yeah, you
should use postgres".
> If you could force MySQL to only
> use innodb tables, and to NEVER do the wrong things syntactically, it
> would be ok.
You'd still need to teach it how to hash-join and everything, though.
Life sucks when the only join type you have is merge join.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Craig A. James 2006-03-30, 3:27 am |
| Gorshkov wrote:
> /flame on
> if you were *that* worried about performance, you wouldn't be using PHP or
> *any* interperted language
> /flame off
>
> sorry - couldn't resist it :-)
I hope this was just a joke. You should be sure to clarify - there might be some newbie out there who thinks you are seriously suggesting coding major web sites in some old-fashioned compiled language.
Craig
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Craig A. James 2006-03-30, 3:27 am |
| This is off-topic for this group so I'll just give a brief reply; I'm happy to carry on more just between the two of us...
Gorshkov wrote:
> That being said ..... what *is* the difference between coding a website -
> major or otherwise - in an "old-fashioned" compiled language and a
> non-compiled language, except for the amount of hoursepower and memory you
> require?
>
> Old-fashioned doesn't mean bad, inappropriate, or inferior. It's just not the
> latest-and-greatest, however it's currently defined by the geek fashion
> police.
Our experience coding web sites with C/C++ versus Perl is about a factor of ten in productivity. We only use C/C++ for CPU-intensive calculations, such as scientific prediction code. Everything else is Perl or Java.
I recently re-coded 10,000 lines of C into 650 lines of Perl. Why? String handling, hash tables, and the simplicity of DBD/DBI. And there was no loss of performance, because the app was strictly I/O bound (that is, Postgres was I/O bound). Sure, the o
ld app may not have been optimal, but we're talking about a factor of 15 reduction in lines of code.
That's not "geek fashion", it's good engineering. Pick the best tool for the job, and learn how to use it.
Craig
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Markus Schaber 2006-03-30, 3:27 am |
| Hi, Craig,
Craig A. James wrote:
> I hope this was just a joke. You should be sure to clarify - there
> might be some newbie out there who thinks you are seriously suggesting
> coding major web sites in some old-fashioned compiled language.
No, but perhaps with a CMS that pregenerates static content, or
http://www.tntnet.org/
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Chris Browne 2006-03-30, 1:31 pm |
| cjames@modgraph-usa.com ("Craig A. James") writes:
> Gorshkov wrote:
>
> I hope this was just a joke. You should be sure to clarify - there
> might be some newbie out there who thinks you are seriously
> suggesting coding major web sites in some old-fashioned compiled
> language.
Actually, this seems not so bad a point...
If people are so interested in micro-managing certain bits of how
performance works, then it seems an excellent question to ask why NOT
write all the CGIs in C.
After all, CGI in C *won't* suffer from the performance troubles
associated with repetitively loading in Perl/PHP frameworks (which is
why things like FastCGI, mod_perl, and such came about), and you can
get a fair level of assurance that the compiled C won't be the
performance bottleneck.
And yes, it does become natural to ask "why not write CGIs in ASM?"
;-)
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www3.sympatico.ca/cbbrowne/lisp.html
"When I was a boy of fourteen, my father was so ignorant I could
hardly stand to have the old man around. But when I got to be
twenty-one, I was astonished at how much the old man had learned in
seven years." -- Mark Twain
| |
|
|
Personally, I'd code it in brainXXXX, for aesthetic reasons.
[color=darkred]
> And that, nowadays, is generally the state of web development. It's not
> the language you're using to write it in, it's how efficiently you're
> using your database. We can probably tweak the system we're testing now
> and get more from our databases by adjusting how hibernate hits them,
> and the types of queries that it's throwing, but in the long run, the
> bottleneck will always be the database server, because we can throw
> relatively small amounts of money at the other layers if they happen to
> be bogging down. Not so much with the database.
So, one wonders why some use 70's languages like Java instead of Lisp or
Python, which are slower, but a lot more powerful and faster to develop
in...
(and don't have hibernate, which is a big bonus)
(why do you think I don't like Java ?)
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Steinar H. Gunderson 2006-03-30, 8:28 pm |
| On Thu, Mar 30, 2006 at 11:31:25PM +0200, PFC wrote:
> So, one wonders why some use 70's languages like Java instead of
> Lisp or Python, which are slower, but a lot more powerful and faster to
> develop in...
> (and don't have hibernate, which is a big bonus)
> (why do you think I don't like Java ?)
Python may not have Hibernate, but it has even worse stuff trying to do about
the same thing. :-)
Anyhow, this is rapidly becoming offtopic for the original thread.
/* Steinar */
--
Homepage: http://www.sesse.net/
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Chris Browne 2006-03-30, 8:28 pm |
| smarlowe@g2switchwor
ks.com (Scott Marlowe) writes:
> And that, nowadays, is generally the state of web development. It's
> not the language you're using to write it in, it's how efficiently
> you're using your database.
Which properly puts my comments in their place :-).
More importantly, that seems like a valid statement which has a *wide*
scope of effects and side-effects. Including some that ought to put
PostgreSQL in a very good place, in that it provides some very good
ways of achieving high efficiency.
Neat performance thing du jour: Hibernate seems to be the "neat new
Java persistence thing."
I have been very unimpressed with some of the web frameworks I have
seen thus far in their interaction with databases.
We use RT (Request Tracker) for tracking tickets, and in its attempt
to be "database agnostic," it actually only achieves being
MySQL(tm)-specific, because they have an automated query generator
that is only good at one style of queries at a time. Coworkers have
suggested improved queries that are (on occasion) hundreds or
thousands of times faster than what it generates; those improvements
fall on deaf ears because they wouldn't work with all the databases.
(Well, more precisely, they wouldn't work with MySQL(tm).)
There's a home grown flavor of Java persistence mapping; it doesn't
seem as heinous as RT's, but it still doesn't make it overly
convenient to replace poor queries with more efficient ones.
Hibernate has a nifty thing in the form of "Named Queries." It'll
often use its own "HQL" to auto-generate SQL, but any time the DBAs
come up with something that's nicely tuned, it seems to be highly
recommended to generate a "Named Query" for that which allows a Nice
Query to be made part of the application without too much weeping and
gnashing of teeth on either DBA or developers' sides.
A framework that allows you to thereby "soup up" how efficiently you
use your database... Hmm... I wonder if that fits into anyone's
notable quote? :-).
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www3.sympatico.ca/cbbrowne/lisp.html
"When I was a boy of fourteen, my father was so ignorant I could
hardly stand to have the old man around. But when I got to be
twenty-one, I was astonished at how much the old man had learned in
seven years." -- Mark Twain
| |
| Philippe Marzin 2006-03-30, 8:28 pm |
| jython is a full rewrite of python in java and interface naturally with
java classes, therefore hibernate ... and is just as easy as python.
Steinar H. Gunderson a écrit :
> On Thu, Mar 30, 2006 at 11:31:25PM +0200, PFC wrote:
>
>
> Python may not have Hibernate, but it has even worse stuff trying to doabout
> the same thing. :-)
>
> Anyhow, this is rapidly becoming offtopic for the original thread.
>
> /* Steinar */
>
| |
| Guido Neitzer 2006-03-31, 3:31 am |
| |
|
|
|
|