[wp-hackers] Porting Wordpress to PostgreSQL

[Andrew Krespanis]

On 3/22/06, John Joseph Bachir <jjb at ibiblio.org> wrote:

> What is y'all's motivation for wanting to use postgres? The usual
> motivation for using one DBMS over another is features, which is obviously
> not the motivation in this case since you are porting an exisitng
> application.
My reason for wanting to support Oracle is because there are a LOT of
universities already heavily invested in Oracle due to it being
required for Blackboard, the leading (*cough - i wish it wasn't true*)
Learning Management System. Seeing as Blackboard just bought their
only competition, this is going to increase over time.
As for postgres, I think those guys are in a similar boat -- if you
can't get MySQL installed for whatever reason, you work with what you
have.

> I can't imagine that  the effort to port to another SQL dialect would be cheaper
> than throwing hardware at the deployment.

What kind of cheapo servers is your company using and where can I get some?! :D
I can't speak for anyone else, but my day job doesn't have MySQL
because our DBA team are all Oracle and that's just the way it is.
Currently the estimate for a 99.xx% uptime MySQL box in our internal
data centre with support and nightly backup is AU$10,000 per year...
yeah, PER YEAR! :-O
There's no way it would cost $10,000 of my time to port WP. Even if it
did, it's a one time investment with periodic upgrades, not the same
fee every year.

> Also you mention that adoDB is fast... it might be fast compared to other
> abstraction layers, but afaik all abstraction layers are slower than
> direct SQL. Or does it have some super fancy caching these days? Much
> fancier than the DBMS' caching systems?

Absolutely -- lowest common denominator SQL (eg: pure ANSI 92) is aka
'slowest common denominator' -- you can't take advantage of anything
offered outside that standard. *However*, the adoDB object has a
lovely method called Prepare($sql); which does nothing on MySQL 4.x.
If you're using just about anything else though (M$SQL, Oracle,
Postgre, probably MySQL5) this will automagically take advantage of
the query caching offered by your target DB.

The best bit of the above query caching features (and other related
functions) is that you can call them for any target DB and adoDB will
know what to use and where. I get very good results using this with
Oracle and would almost go so far as to say any DB offering query
caching would slay MySQL for pure content output under heavy load.
(working under the pretence that PHP level cahcing isn't also
happening, which it should be). However, that's too hard to prove and
far too debatable, so I'm going to walk away from that statement ;)

To reiterate  -- abstraction is often referred to as a pretty term for
_slow_. Working off the php version of adoDB is fine, but the C
extension is truly awesome.
Also, adoDB 4.8 implements the Active Record pattern in a very similar
manner to the intentions of the Zend Framework (although Zend haven't
released that code yet afaik); although it actually is a more feature
rich implementation.

-Andrew