With all respect as a long-time and still-current psql user... who the flip uses psql who cares all that much about speed?

Need to pick a Canadian carrier in Vancouver... any suggestions?

Web Scale: I fully expect that one time I'll build something so totally awesome that I'll have 10 users. I want all of them to think: "Wow, this application is so fast and responsive. Are they using MongoDB?"

Look at the press release: http://www.postgresql.org/about/news/1415/

a leap forward in performance, scalability

addition of linear scalability to 64 cores, index-only scans and reductions in CPU power consumption, PostgreSQL 9.2 has significantly improved scalability

Improvements in vertical scalability

the addition of cascading replication enables users to run even larger stacks of horizontally scaled servers

C'mon: this doesn't make you feel warm and fuzzy inside?

isn't the correct procedure to install 9.2 first then use it's newer pg_dump on the old database? also pg_dumpall should include everything, tables and triggers for sure!

either way I'd rather not uninstall before the new version was up and running 100%

Looks like you have a few choices if this is accurate.

what do you use if you care about speed?

Well traditionally my answer to that is MySQL, because the last time I researched it they made some pretty strong tradeoffs in favor of speed.

Been a while since I made a decision like that though to be honest. The last umpteen million web deployments I've done have been Wordpress/MySQL.

I have no idea what the correct procedure. According to the docs, the "traditional method" is to do the dump. I wasn't sure if that meant using upgrade is discouraged, but there was an underlying suggestion that using pg_upgrade isn't as dependable as a dump.

I mean, I don't have any important data, and I have all the dependencies saved in a sql file anyways, so if the dump fails and I have to revert, it's pretty simple.

Actually one thing I'd take a serious look at, depending on the size of the data set involved, would be sqlite. If it fits in cache it's effectively in memory.

Buy a tube of lube.

Canadian cell phone carriers and plans blow chunks compared to most of the rest of the world.

FTR I use Bell. I find them slightly less horrible than Rogers.

To be fair, at the level I'm at, there's no justifiable reason to pick any RDBMS over another. I do know that PostgreSQL has gotten considerably faster and MySQL has traded its speed for more features. I'm under the impression that the speed differences at this point are negligible.

I think this is an interesting article on the history and how they are different:
http://ledgersmbdev.blogspot.co.uk/2...gresql-vs.html

Some SO stuff with speed-test links.
http://stackoverflow.com/questions/8...ns-w-gis-speed

I'm not convinced either way.

Heh. When I actually got to stretch my legs, and wrote my calorie counter tool with Ramaze, going web based so that I could easily keep on my plan on a trip, I just used MySQL because I didn't feel like putting psql on my web server. That made me sad. I wish I'd thought of sqlite for that project. Then I would have gotten completely out of the rut for a change.

Oh well, at least I got to use Ruby and sqlite for my MailChimp segmenter. Which reminds me, I need to run a segment tonight...

I use Koodo (piggy backs on Bell's network) and have been quite happy with them.

I *hate* Rogers & Bell.

You may be thinking of the improvements to InnoDB engine. In MySQL 5.5 InnoDB became the default engine, and it's much improved.

The tradeoff you may be thinking of is the innodb-flush-log-at-trx-commit=2 setting. If you don't need ACID compliance and you can survive losing the last second of transactions in a crash, there are big performance gains from setting this to 2.

Here's a white paper Oracle released, but the highlights are 200% performance and scalability gain in MySQL 5.5 over 5.1 for read only activity and 370% gain for read/write activity.

Nah I'm talking about before InnoDB, when they only had one engine, but yes the tradeoff was not exactly trying to be close to ACID compliant.

The database movement went off without a hitch... almost. The triggers didn't migrate, but I had them stored anyways so that was not a huge hassle.

I have no idea why though, that I update the database, the data goes into the database, yet I get a null pointer exception...?

Heh whee. No switching providers for me after all. AT&T deployed LTE into Leesburg in the last month. Still won't have it at the office, but it means 2 hours of my 2.5 hour commute are now LTE covered under AT&T.

Maybe someone who does Java interop to databases with the JDBC can answer this one:

I have a form field, and namely the issue seems to revolve around a numeric (int) field. Everything in the fields insert into the database, but I get a null pointer exception. Is there any reason that something like this is happening specifically with numeric (int) fields?

Should I just override this exception and assume everything is going okay?

I guess one issue is that the lazy seq in Clojure creates problems. I've attempted to create local bindings to the values before they are inserted, but I guess this isn't working.

I guess I'll finish the last of this stuff tonight and research this later, but is Java database work really this painful?

Totally random suggestion - check anywhere that autoboxing (or unboxing I guess) is happening. If your database field can be null and you're trying to treat the value as an int - as opposed to an Integer - I think you'll get a npe.

I remember spending an hour or so not too long ago with a weird null pointer exception that was caused by autoboxing.

Edit: As for the general Java database work comment - maybe? It use to be pretty painful when you had to a lot of stuff manually but I think drivers have gotten a lot better and ORMs can sometimes avoid pain. I've been using Mongo the last couple of years and their driver is quite good. I can't remember any real problems with it.

Ye, I am on Chatr at the moment which seems to be the only vaguely cheap network (part of Rogers), but even that is a ripoff.

Was looking at Bell and will probably go with them but fk me phones are expensive here!

congrats again on your big move.

Thanks

I needed out of there so bad.

I'm very happy in VA.

neil, does that mean you drive 5 hours a day? or 2.5 hours total? or is it on a train?

2 trains, 2 buses. 2.5 hours one way.

But it's an average of only 2 days a week that I actually have to go. This week it'll be 3. They never make me do back to backs either.

wow that seems insane. can you work on a laptop?