Thread: Request Tracker ( RT ) recommends MySQL
I've been away from the site and mailing list for better than a year so was surprised as all get out that MySQL is ther recommended database for RT. The version I installed over four years ago uses Pg. My question is does anyone know why they decided to go with MySQL? ( Pg 7.3 or above is an alternative; as is Oracle ). I would ask the RT list but don't want to get into any flaming combats and was hoping someone here might know ( having risked being charred. ) Thanks, Rod --
I have a 3.4.3 RT using PG quite happily. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US -----Original Message----- From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy-owner@postgresql.org] On Behalf Of Roderick A. Anderson Sent: Thursday, September 08, 2005 10:51 PM To: Pg Advocacy Subject: [pgsql-advocacy] Request Tracker ( RT ) recommends MySQL I've been away from the site and mailing list for better than a year so was surprised as all get out that MySQL is ther recommended database for RT. The version I installed over four years ago uses Pg. My question is does anyone know why they decided to go with MySQL? ( Pg 7.3 or above is an alternative; as is Oracle ). I would ask the RT list but don't want to get into any flaming combats and was hoping someone here might know ( having risked being charred. ) Thanks, Rod -- ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
raanders@acm.org ("Roderick A. Anderson") writes:
> I've been away from the site and mailing list for better than a year
> so was surprised as all get out that MySQL is ther recommended
> database for RT. The version I installed over four years ago uses
> Pg.
>
> My question is does anyone know why they decided to go with MySQL?
> ( Pg 7.3 or above is an alternative; as is Oracle ). I would ask
> the RT list but don't want to get into any flaming combats and was
> hoping someone here might know ( having risked being charred. )
The application was written specifically for MySQL(tm), and much of the
internals function in a manner optimized for MySQL(tm).
And while the prebuilt installations on FreeBSD, Debian, and Gentoo
allow choosing between MySQL and PostgreSQL (and *possibly* SQLite),
tho the Debian install guide notes that converting from RT2 to RT3
isn't PostgreSQL-friendly...
On both Red Hat and Windows(tm) systems, the "prebuilt" builds are, to
this day, MySQL-specific.
<http://wiki.bestpractical.com/index.cgi?WindowsOSInstallGuide>
<http://wiki.bestpractical.com/index.cgi?RPMInstall>
One of our people did some performance tuning work, and found a number
of queries that could be made *spectacularly* faster for PostgreSQL if
tweaked to be less MySQL(tm)-specific (I surmise that the same changes
would be either helpful or at least not hurtful for Oracle, Informix,
and Sybase, though I can't be sure about SQLite).
Unfortunately, since the tweaks go beyond the SQL capabilities of
MySQL, Best Practical couldn't use the changes.
Considering it from their perspective, historically, RT used to run
only atop MySQL(tm). So any "legacy" users, who used MySQL(tm), are
running that, presumably with some degree of
satisfaction/acquiescence. Doing anything that breaks MySQL(tm)
compatibility would injure those users.
The notion that RT "works best" with MySQL(tm) shouldn't appear
terribly alien. It was indeed designed to "work best" with MySQL(tm),
and the vendor can't afford to change that.
[Note: MySQL is a registered trademark of MySQL AB; Windows is a
trademark of Microsoft Corporation; Oracle, Informix and Sybase are
doubtless also registered trademarks of notable companies containing
the respective strings...]
--
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://www.ntlug.org/~cbbrowne/internet.html
He's not dead. He's electroencephalographically challenged.
> One of our people did some performance tuning work, and found a number > of queries that could be made *spectacularly* faster for PostgreSQL if > tweaked to be less MySQL(tm)-specific (I surmise that the same changes > would be either helpful or at least not hurtful for Oracle, Informix, > and Sybase, though I can't be sure about SQLite). Note that the best way to change this situation is for users of RT to request these changes. There's no real reason they can't support alternative query syntaxes for different databases, other than it's more work. If anything, they should make MySQL the exception case, and use normal SQL syntax for everyone else. But none of this will change unless people using the product (especially those sending them money) request it. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: >>One of our people did some performance tuning work, and found a number >>of queries that could be made *spectacularly* faster for PostgreSQL if >>tweaked to be less MySQL(tm)-specific (I surmise that the same changes >>would be either helpful or at least not hurtful for Oracle, Informix, >>and Sybase, though I can't be sure about SQLite). >> >> > >Note that the best way to change this situation is for users of RT to >request these changes. There's no real reason they can't support >alternative query syntaxes for different databases, other than it's more >work. If anything, they should make MySQL the exception case, and use >normal SQL syntax for everyone else. But none of this will change unless >people using the product (especially those sending them money) request >it. > > I'm the one that Chris mentioned that did the performance tuning on RT. Best Practical are really good people to work with, but they will only use code that will work across all databases the support. There was one query in particular that made really horrible use of OR clauses. I sent in details on how to rewrite the query using unions, which changed it query from a "execute your query and go make coffee" type of query to one that completed in a very reasonable period of time. I was told that it wasn't an option because MySQL didn't have Unions. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
jnasby@pervasive.com ("Jim C. Nasby") writes:
>> One of our people did some performance tuning work, and found a
>> number of queries that could be made *spectacularly* faster for
>> PostgreSQL if tweaked to be less MySQL(tm)-specific (I surmise that
>> the same changes would be either helpful or at least not hurtful
>> for Oracle, Informix, and Sybase, though I can't be sure about
>> SQLite).
>
> Note that the best way to change this situation is for users of RT
> to request these changes. There's no real reason they can't support
> alternative query syntaxes for different databases, other than it's
> more work. If anything, they should make MySQL the exception case,
> and use normal SQL syntax for everyone else. But none of this will
> change unless people using the product (especially those sending
> them money) request it.
What you're proposing is not really to "make MySQL the exception
case," but rather to cease to support it as an option.
It's only going to be convincing if the vendor can be convinced that
dropping support for their legacy of customers who are not unhappy
with MySQL(tm) is the preferred approach. They have not been easy to
convince thus far.
--
output = reverse("gro.gultn" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/advocacy.html
"I find it hard to believe a professional programmer could support the
concept of Open Source." -- David J. Owens <owensdj@home.net>
On Sat, Sep 10, 2005 at 01:12:45AM -0400, Chris Browne wrote:
> jnasby@pervasive.com ("Jim C. Nasby") writes:
> >> One of our people did some performance tuning work, and found a
> >> number of queries that could be made *spectacularly* faster for
> >> PostgreSQL if tweaked to be less MySQL(tm)-specific (I surmise that
> >> the same changes would be either helpful or at least not hurtful
> >> for Oracle, Informix, and Sybase, though I can't be sure about
> >> SQLite).
> >
> > Note that the best way to change this situation is for users of RT
> > to request these changes. There's no real reason they can't support
> > alternative query syntaxes for different databases, other than it's
> > more work. If anything, they should make MySQL the exception case,
> > and use normal SQL syntax for everyone else. But none of this will
> > change unless people using the product (especially those sending
> > them money) request it.
>
> What you're proposing is not really to "make MySQL the exception
> case," but rather to cease to support it as an option.
>
> It's only going to be convincing if the vendor can be convinced that
> dropping support for their legacy of customers who are not unhappy
> with MySQL(tm) is the preferred approach. They have not been easy to
> convince thus far.
There's no technical reason I can think of why a piece of software
couldn't support different queries for different databases. They may
choose not to (which it sounds like they've done). Of course if enough
people complain, they might well change their mind as well.
On the flip-side, PostreSQL's optimizer does seem to be pretty picky
about query syntax; there's probably a fair amount that could be done to
improve how it plans certain cases.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote:
>On Sat, Sep 10, 2005 at 01:12:45AM -0400, Chris Browne wrote:
>
>
>>jnasby@pervasive.com ("Jim C. Nasby") writes:
>>
>>
>>>>One of our people did some performance tuning work, and found a
>>>>number of queries that could be made *spectacularly* faster for
>>>>PostgreSQL if tweaked to be less MySQL(tm)-specific (I surmise that
>>>>the same changes would be either helpful or at least not hurtful
>>>>for Oracle, Informix, and Sybase, though I can't be sure about
>>>>SQLite).
>>>>
>>>>
>>>Note that the best way to change this situation is for users of RT
>>>to request these changes. There's no real reason they can't support
>>>alternative query syntaxes for different databases, other than it's
>>>more work. If anything, they should make MySQL the exception case,
>>>and use normal SQL syntax for everyone else. But none of this will
>>>change unless people using the product (especially those sending
>>>them money) request it.
>>>
>>>
>>What you're proposing is not really to "make MySQL the exception
>>case," but rather to cease to support it as an option.
>>
>>It's only going to be convincing if the vendor can be convinced that
>>dropping support for their legacy of customers who are not unhappy
>>with MySQL(tm) is the preferred approach. They have not been easy to
>>convince thus far.
>>
>>
>
>There's no technical reason I can think of why a piece of software
>couldn't support different queries for different databases.
>
Nope, but I'd imagine that it's the maintenance overhead that they are
concerned about.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.
> I'm the one that Chris mentioned that did the performance tuning on RT. > Best Practical are really good people to work with, but they will only > use code that will work across all databases the support. There was one > query in particular that made really horrible use of OR clauses. I sent > in details on how to rewrite the query using unions, which changed it > query from a "execute your query and go make coffee" type of query to > one that completed in a very reasonable period of time. I was told that > it wasn't an option because MySQL didn't have Unions. MySQL 4 has unions...
On 9/29/2005 3:44 AM, Christopher Kings-Lynne wrote: >> I'm the one that Chris mentioned that did the performance tuning on RT. >> Best Practical are really good people to work with, but they will only >> use code that will work across all databases the support. There was one >> query in particular that made really horrible use of OR clauses. I sent >> in details on how to rewrite the query using unions, which changed it >> query from a "execute your query and go make coffee" type of query to >> one that completed in a very reasonable period of time. I was told that >> it wasn't an option because MySQL didn't have Unions. > > MySQL 4 has unions... ... as well as a different license for the client library. Might not be a problem for RT itself, but you know, some people have multiple databases with different applications, so 3.x backward support has some value in it. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
JanWieck@Yahoo.com (Jan Wieck) writes: > On 9/29/2005 3:44 AM, Christopher Kings-Lynne wrote: > >>> I'm the one that Chris mentioned that did the performance tuning on >>> RT. Best Practical are really good people to work with, but they >>> will only use code that will work across all databases the support. >>> There was one query in particular that made really horrible use of >>> OR clauses. I sent in details on how to rewrite the query using >>> unions, which changed it query from a "execute your query and go >>> make coffee" type of query to one that completed in a very >>> reasonable period of time. I was told that it wasn't an option >>> because MySQL didn't have Unions. >> MySQL 4 has unions... > > ... as well as a different license for the client library. Might not > be a problem for RT itself, but you know, some people have multiple > databases with different applications, so 3.x backward support has > some value in it. Furthermore, the fact that RT's code is owned by Best Practical rather than Some Other Company means that there are irreconcilably dueling licenses even though it's essentially the same license all around... -- (format nil "~S@~S" "cbbrowne" "cbbrowne.com") http://cbbrowne.com/info/ "Waving away a cloud of smoke, I look up, and am blinded by a bright, white light. It's God. No, not Richard Stallman, or Linus Torvalds, but God. In a booming voice, He says: "THIS IS A SIGN. USE LINUX, THE FREE Unix SYSTEM FOR THE 386." -- Matt Welsh