Mangus Hagander has a detailed how to for replicating from MS SQL Server to PostgreSQL. It certainly isn’t perfect, but for those willing to go through the work this would be a very interesting way to add PostgreSQL to a SQL Server shop. I don’t plan on using this right now, but I’m definitely going to file this away as something with potential.
Monthly Archives: April 2006
PowerBook Problems
Yesterday was a bummer. The hard drive on 15″ PowerBook G4 died. Thankfully the folks at the Apple Store at Arden Fair Mall replaced it quickly, after I spent the $99 for Pro Care. I dropped it off yesterday afternoon and it was ready first thing this morning. It was still under the three year warranty so the repair didn’t cost anything.
After I got back to the office this morning I noticed that the system only showed 1 Gig of RAM instead of the 2 that I had before. Back to the Apple Store. Both of the memory sticks were still in the system, but it would only recognize one slot. Looks like the logic board is going to need replacing. To see if I could get things done any faster I went to the CSU Sacramento Computer Store where they have an Apple tech on site. He seemed to think that it was just one of the memory chips that was bad. So we pulled the bad one with then intent that it would get replaced next week (there was a life time warranty on the memory).
Back to the office one more time. The system would work for a few minutes and then freeze. Then it wouldn’t boot. Then it paniced while booting. Ug, not good. So then I moved the one remaining memory stick from the slot it was in into the other other slot (there are only two slots). After that it has been fine. Looks like the Apple store folks were right, the logic board needs to be replaced. Ick.
I’m bummed to spend so much of the day running around trying to get my two year old PowerBook G4 going again. While I still do a lot of (I mean a lot) of Windows work, not having Unix like guts on my primary development system is a real pain. Of course if things got bad enough perhaps work would spring for a new MacBook Pro
Hey, I can dream.
Boot Camp
Apple announced a public beta of Boot Camp, which helps you install Windows XP on your Intel based Apple hardware. This includes drivers for graphics, networking, audio, wireless and bluetooth.
I’ve got to get this out of my system first: This Is So Freaking Cool! Okay, I feel better now.
With Boot Camp you can dual boot between Windows XP and Mac OS X. Details are still coming out, but I’m going to guess that this contains updates to EFI to support BIOS dependent operating systems. If that is the case then you should be able to multi-boot between other operating systems also (like FreeBSD or Ubuntu). Perhaps even Windows Vista when it is released. If you combined this with something like Mac Drive 6, which allows Windows to read/write to HFS/HFS+ (the Mac OS X file system), you’ll have a pretty reasonable setup.
Boot Camp will be included in the next version of Mac OS X (10.5) Leopard. I don’t believe that a release date has been talked about yet for Leopard, but we are supposed to hear more this summer (August). This also brings into question the rumors about virtualisation software being included in Leopard. How far with Apple really go with allowing/supporting other operating systems on their hardware? As much as I’d like to see this rumor be true, part of me things that it isn’t likely that Apple as a company would be thrilled with the idea. They have to draw the line some where on encouraging people to use non-OS X software.
At this point I see Boot Camp as good news for Apple and consumers. For die hard Apple fans this won’t change anything, but it makes for one more reason for Windows users to make their next computer a Mac instead of a traditional PC.
PHP Database Functions vs. PEAR::DB vs. ADOdb (and PDO)
I started putting together a few small PHP scripts to move data around. I’ve been using PEAR::DB a fair bit for this sort of thing, but I figured there wasn’t really much reason for it in this case since I knew these were only going to be talking to specific databases and wouldn’t be ported for anything else. This got me to wondering what sort of performance penalty I was paying for using PEAR::DB instead of the specific PHP functions. This lead to a few simple test scripts against a PostgreSQL database.
The first script uses the PHP PostgreSQL functions directly:
ini_set("display_errors", 1);
$time_start = microtime(true);
$db = pg_connect("host=dbserver dbname=testdb user=test password=testpw");
$runs = 250;
for($i = 0; $i = '25-MAR-06'";
$rs = pg_query($db, $sql);
while($row = pg_fetch_assoc($rs)) { }
}
$time_end = microtime(true);
$time = $time_end - $time_start;
print("TIME: {$time}\\n");
Nothing too exciting, just run the same query 250 times and ditch the results. This query happens to return 273 rows against my test database. I ran this script from the command line 10 times. The fastest time for this script was 3.6526100635529 seconds. Normally I’d include error checks in these, but I was only interested in how fast I could get through data. The second script made use of PEAR::DB:
ini_set("display_errors", 1);
require_once("PEAR.php");
require_once("DB.php");
$time_start = microtime(true);
$db = DB::Connect("pgsql://test:testpw@dbserver/testdb");
$runs = 250;
for($i = 0; $i = '25-MAR-06'";
$rs = $db->query($sql);
while($row = $rs->fetchRow()) { }
}
$time_end = microtime(true);
$time = $time_end - $time_start;
print("TIME: {$time}\\n");
Same conditions, run 10 times from the command line with the same 273 rows returned from the query. The fastest time was 6.5583028793335 seconds. So PEAR::DB added an additional 2.90569281578 seconds to the process, an increase of almost 80%.
Just add more data to the mix I put together another script using ADOdb:
ini_set("display_errors", 1);
require_once("./adodb/adodb.inc.php");
$time_start = microtime(true);
$ADODB_FETCH_MODE = ADODB_FETCH_ASSOC;
$db = NewADOConnection("postgres://test:testpw@dbserver/testdb");
$runs = 250;
for($i = 0; $i = '25-MAR-06'";
$rs = $db->Execute($sql);
while(!$rs->EOF) { $rs->MoveNext(); }
}
$time_end = microtime(true);
$time = $time_end - $time_start;
print("TIME: {$time}\\n");
Once again 10 runs from the command line with 273 rows being returned from the query. The fastest time was 5.3411331176758 seconds. Faster than PEAR::DB by more than a second, but still well behind the script that used the direct database functions by 1.68852305412 seconds. This is about 46% slower compared to PEAR::DB’s almost 80%.
I should note that I tried to include PEAR::MDB2 in the test but it kept giving me reference errors. I modified my test script to deal with a couple of them, but gave up after more of them showed up.
What does all this mean? Here is what I take from it:
- If you need performance over supporting multiple databases and use of PEAR packages that require PEAR::DB (like PEAR::DB_DataObject) then stick with calling the database functions directly. No way to beat that from a performance perspective.
- If you need to support multiple databases and don’t have to worry about other PEAR packages then go with ADOdb. It is faster than PEAR:DB good margin.
- If you are using other PEAR packages that require PEAR::DB then go with that.
This wasn’t intended to be an exhaustive test, I just wanted to get a feeling for the relative speed of these three options. For reference I used PHP 5.1.2 on a FreeBSD 6 system. If you run a similar comparison be sure to look at the relative differences between the times, not the times themselves.
UPDATE Tue 4 Apr 2006 @ 4:30pm : Philip Hofstetter pointed out that I should have included the new PDO functions in my test. So here it is:
ini_set("display_errors", 1);
$time_start = microtime(true);
$db = new PDO("pgsql:host=dbserver dbname=testdb user=test password=testpw");
$runs = 250;
for($i = 0; $i = '25-MAR-06'";
foreach($db->query($sql) as $row) { }
}
$time_end = microtime(true);
$time = $time_end - $time_start;
print("TIME: {$time}\\n");
Once again 10 runs from the command line, with the query returning 273 rows. The fastest time was 4.287976026535 seconds. So PDO comes in at number two, beating ADOdb by more than a second. But still behind direct function calls by more than six tenths of a second, adding only 17% over head. PDO will only work with PHP 5, so if you want/need your app to work with PHP 4 then don’t even include PDO on your list of options.
UPDATE Tue 11 Apr 2006 @ 12:10am : Deane over at Gadgetopia.com wanted to know how the ADOdb extension faired in this test. So here we are one more time
After installing the ADOdb extension I ran the same exact test script for ADOdb 10 times from the command line with the same query returning 273 rows. The unmodified script returned times that were very close to the numbers with ADOdb without the extension. The fastest time was 5.3139600753784 seconds, only 0.027173 seconds faster than plain ADOdb. To test out the speed of the extension I made one change to the test script, using adodb_movenext($rs); instead of $rs->MoveNext(); in the while loop:
ini_set("display_errors", 1);
require_once("./adodb/adodb.inc.php");
$time_start = microtime(true);
$ADODB_FETCH_MODE = ADODB_FETCH_ASSOC;
$db = NewADOConnection("postgres://test:testpw@dbserver/testdb");
$runs = 250;
for($i = 0; $i = '25-MAR-06'";
$rs = $db->Execute($sql);
while(!$rs->EOF) {
# $rs->MoveNext();
adodb_movenext($rs);
}
}
$time_end = microtime(true);
$time = $time_end - $time_start;
print("TIME: {$time}\n");
Another 10 runs from the command line and the fastest time was 4.2841749191284 seconds. This is 1.0569582 seconds faster than ADOdb without the extension. This is ever so slightly faster than PDO, beating it out by 0.0038011. Calling the direct database functions are still 0.6315648 seconds faster than ADOdb + ADOdb-extension.
To make things easier here is a table of the results. Remember that the focus is on the relative differences, not the specific times, which will vary with different hardware/OS/etc. All times are given in seconds.
| Library/Function | Time | Absolute Difference |
|---|---|---|
| Direct database functions | 3.6526100635529 | 0 |
| ADOdb + ADOdb/extension | 4.2841749191284 | 0.6315648 |
| PDO | 4.287976026535 | 0.6353659 |
| ADOdb (w/o extension) | 5.3411331176758 | 1.688523 |
| PEAR::DB | 6.5583028793335 | 2.9056928 |
Using the specific database functions still wins, I suspect they always will. Interesting that PDO didn’t beat out ADOdb + ADOdb/extension, although the times are so close that it is probably a wash.
Moving gd Development To php.net
Thomas Boutell is a name that brings back a flood of memories from the days of my first serious exposure to the Internet. (yeah Wired I spelled it with an I, wanna fight about it?) So it was kind of surprising to see his name show up on a post to the PHP Developers list. What was even more interesting was what Thomas proposed in that email.
Thomas Boutell proposed moving gd development to php.net. Yes that GD. Based on the response from Rasmus, Pierre stepping up to maintain it and the acceptance by Thomas it looks like this is going to be a done deal. I’m glad to see that folks involved in this transition were able to come to an agreement so quickly.
I wanted to take a moment to wish Thomas the best of luck on the other projects that he has moved on to. Like many others I’ve benefited from his work on GD and other bits of code and articles, especially in my early days of working on web.