Re: [development] Do not let postgresql hold back great patches
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Take, for example, that COUNT(*) is _really_ fast on MySQL + MyISAM, but is slow on just about every other DB. So, replace it with $db->count(), which does an SQL COUNT(*) on MySQL + MyISAM, but uses some other technique on other databases. The programmer no longer cares _how_ such a thing gets done, he only cares that he wants to know how many rows are in a particular query
The primary problem with this approach (at least in my experience) is that the moment you need to create queries that are even somewhat complicated the abstraction layer proves to be insufficient. Ad hoc queries are often very useful for performance reasons, but you'll have to get a PostgreSQL guru to write an equivalent. Then again, for most people writing SQL performance/complex joins/etc are not a primary concern... - -- Edward Z. Yang Portable GnuPG: 0x995A2C84 HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter [[ C8D5 9E3C 15AD 1467 5561 2C0E 719A 2D9D 995A 2C84 ]] This Message Courtesy of Thunderbird Portable -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHUE9NcZotnZlaLIQRAomgAJ9JvBtXwUnv94O873gXej1pmTUVhACfSr3e q5b1On3RkByDzPboq9PM2zI= =CPMZ -----END PGP SIGNATURE-----
In response to "Edward Z. Yang" <edwardzyang@thewritingpot.com>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Take, for example, that COUNT(*) is _really_ fast on MySQL + MyISAM, but is slow on just about every other DB. So, replace it with $db->count(), which does an SQL COUNT(*) on MySQL + MyISAM, but uses some other technique on other databases. The programmer no longer cares _how_ such a thing gets done, he only cares that he wants to know how many rows are in a particular query
The primary problem with this approach (at least in my experience) is that the moment you need to create queries that are even somewhat complicated the abstraction layer proves to be insufficient. Ad hoc queries are often very useful for performance reasons, but you'll have to get a PostgreSQL guru to write an equivalent.
Then again, for most people writing SQL performance/complex joins/etc are not a primary concern...
Well, if such an abstraction solves 90% of the problems, the gurus will have more time to deal with the remaining 10%. Assuming it can be done well enough to actually solve 90%. -- Bill Moran http://www.potentialtech.com
On Nov 30, 2007 7:40 PM, Bill Moran <wmoran@potentialtech.com> wrote:
Then again, for most people writing SQL performance/complex joins/etc are not a primary concern...
Well, if such an abstraction solves 90% of the problems, the gurus will have more time to deal with the remaining 10%.
That was the intention of my idea -- not replace all SQL, but replace all mundane SQL so efforts can be focused on the hard/complex/performance-needing queries.
participants (3)
-
Bill Moran -
Chris Johnson -
Edward Z. Yang