Postgres vs mysql

RT Users
1

Hi,

Various threads here, and on the website, mention that mysql is
recommended as a database backend for RT rather than postgresql.

Does anyone have any evidence showing why? I am particularly interested
in any performance figures/anecdotes.

Thanks in advance.

John

2

John Green:

Various threads here, and on the website, mention that mysql is
recommended as a database backend for RT rather than postgresql.

Does anyone have any evidence showing why? I am particularly interested
in any performance figures/anecdotes.

Two major reasons:
1) Postgres is big, grand, and feature-complete. mysql is lightweight,
fast and does just enough SQL for RT to be happy.
2) Postgres can’t handle embedded nulls in binary objects, so RT has to
muck about with base 64 encoding in some cases, which is slow.

There’s something else to do with case sensitivity but I can’t remember it.

If the code and the comments disagree, then both are probably wrong.
– Norm Schryer

3

Hi,

Various threads here, and on the website, mention that mysql is
recommended as a database backend for RT rather than postgresql.

Does anyone have any evidence showing why? I am particularly
interested in any performance figures/anecdotes.

Thanks in advance.

John

This has nothing to do with performance per se, IIRC. RT was/is
traditionally designed with the MySQL backend, and thus it is in use
for most installations. If You use postgres, You need to know what You
are doing even more than when using MySQL, where others can give You
specific advice on using it with RT.

It might be the database schemas are not as well designed for postgres
as for MySQL, which could lead to a performance hit.

Regards,
Harald

Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg

4

Two major reasons:
2) Postgres can’t handle embedded nulls in binary objects, so RT has to
muck about with base 64 encoding in some cases, which is slow.

Couldn’t. Now that DBD::Pg supports bytea types properly, this is no
longer the case. It should be changed for 3.0.

There’s something else to do with case sensitivity but I can’t remember it.

By default, mysql isn’t case sensitive, postgresql is.

–
If the code and the comments disagree, then both are probably wrong.
– Norm Schryer

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

5

“SC” == Simon Cozens rt@netthink.co.uk writes:

SC> Two major reasons:
SC> 1) Postgres is big, grand, and feature-complete. mysql is lightweight,
SC> fast and does just enough SQL for RT to be happy.
SC> 2) Postgres can’t handle embedded nulls in binary objects, so RT has to
SC> muck about with base 64 encoding in some cases, which is slow.

If you’ve already got a postgres installation running, then use it.
There’s no reason to add mysql to your maintanance issues in that
case. If you’re starting from scratch, then either one will do,
really. Personally, I use postgres since that is our standard
database here.

Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/