2) Use persistent connections. Everyone likes to point out the forking issue with PG vs. MySQL's threaded. PG's connection handling is slow, there's no doubt about it. But there's an easy answer. Just limit how often you connect. If you can keep a connection pool, and just reuse those connections, you'll save this big hit. True that. On an earlier project I ended up going with the psycopg module for python which allows you to keep a number of connections open. It worked like a charm.
As a rather dense guy who tends to get a little huffy when I'm forced to read anything other than "QUICKSTART", I must agree.
At least on OpenBSD, PostGreSQL is more fiddly and difficult to install than MySQL (usually the handy comments that the OpenBSD folks add at the end of the pkg_add process give you enough to go on. Theo and the others tend to do most of the thinking ahead for you. More time for me to rock back and forth staring at last months regex &c...)
In the *very limited* scope of my testing before the descision was made for me, the two were about the same for our needs, except that massive amounts of UPDATEs were noticeably slower on MySQL - but pulling my head out of my sphincter and using stored procedures for the big updates solved most of that. In fact I suspect that much of the mahooha spouted about both of these projects is coming from the same folks responsible for some of the truly clowny queries in some very popular projects I downloaded when I was learning how to be a merely mediocre accessor of SQL services.:-)
A poster above asserts that many projects would be better off using flat files. I must agree. In fact, one could argue that MySQL's ease of installation is (through no fault of the fine folks at MySQL AB) responsible for many misused resources. I only started using SQL in the past couple of years. Most of my projects were simply reading data into web pages with only two (100k =-) updates per daily cycle, simply using BerkeleyDB (python's anydbm module treats it as a dictionary type, making it ridiculously easy to use) was a much better choice. I've never pestered my provider for an overhead comparison vis modpython vs modpython+MySQL, but I'm betting there's an appreciable advantage with the flat db (or just a text file) for low-to-medium traffic site (did I just sin against relativity here?).
When I read this I thought: "Why would they change that name? Leibniz was so very prescient and... Oh. *blink* It reads as if it rhymes with 'gonad' doesn't it?"
I don't know what it does yet, but my next Free Software project is going to be called "One-Ball McGillicuddy" in reaction.
I dunno. Since the Lasik and the perm, Al is actually a fairly good looking guy now. My former business partner is a very attractive female. She sweats his parodic ostimoticles.
Slashdot Mirror
Apparently PostGreSQL enjoys an extra processor!
:-)
Of course, the article is mainly a review of a couple of dual Intel Xeon 5160 systems, so I'm unsure what the pretty graphs mean.
As a rather dense guy who tends to get a little huffy when I'm forced to read anything other than "QUICKSTART", I must agree.
...)
:-)
At least on OpenBSD, PostGreSQL is more fiddly and difficult to install than MySQL (usually the handy comments that the OpenBSD folks add at the end of the pkg_add process give you enough to go on. Theo and the others tend to do most of the thinking ahead for you. More time for me to rock back and forth staring at last months regex &c
In the *very limited* scope of my testing before the descision was made for me, the two were about the same for our needs, except that massive amounts of UPDATEs were noticeably slower on MySQL - but pulling my head out of my sphincter and using stored procedures for the big updates solved most of that. In fact I suspect that much of the mahooha spouted about both of these projects is coming from the same folks responsible for some of the truly clowny queries in some very popular projects I downloaded when I was learning how to be a merely mediocre accessor of SQL services.
A poster above asserts that many projects would be better off using flat files. I must agree. In fact, one could argue that MySQL's ease of installation is (through no fault of the fine folks at MySQL AB) responsible for many misused resources. I only started using SQL in the past couple of years. Most of my projects were simply reading data into web pages with only two (100k =-) updates per daily cycle, simply using BerkeleyDB (python's anydbm module treats it as a dictionary type, making it ridiculously easy to use) was a much better choice. I've never pestered my provider for an overhead comparison vis modpython vs modpython+MySQL, but I'm betting there's an appreciable advantage with the flat db (or just a text file) for low-to-medium traffic site (did I just sin against relativity here?).
Although the nun smacked my hams
I gleefully clutched MyISAM
That pretty much scans, I think.
You laugh now! Poor kitties.
Charles Stoss' Aineko character gives me the eebiejeebies. I have been very suspicious of my Roomba ever since reading this.
When I read this I thought: "Why would they change that name? Leibniz was so very prescient and ... Oh. *blink* It reads as if it rhymes with 'gonad' doesn't it?"
I don't know what it does yet, but my next Free Software project is going to be called "One-Ball McGillicuddy" in reaction.
Thanks for giving me the straight poop on my inbox. I wonder if he tosses quicklime or salt into your junk folder before entering?
... if you start talking about using POKE without a manual we're leaving. Seriously.
What is up with the Pooping Sumo Wrestler in the ad next to the article?
*brrrr*
I dunno. Since the Lasik and the perm, Al is actually a fairly good looking guy now. My former business partner is a very attractive female. She sweats his parodic ostimoticles.
Alfalfa: "Hey fellers! Let's turn this old mac plus into a reputation server!"
..."
Spanky: "Oh Boy!"
BuckWheat: "Oh-Tay"
Mickey: "I don't like that idea at all. Sometimes people jump to conclusions
Darla: "Oh you nasty man."