[Asterisk-Dev] PostgreSQL support in Asterisk 1.2?
Andrew Kohlsmith
akohlsmith-asterisk at benshaw.com
Fri Aug 5 06:34:46 MST 2005
On Thursday 04 August 2005 22:21, Adam Goryachev wrote:
> They also install asterisk on a P1-133MHz machine with 16 MB RAM and
> moan about poor audio quality when running 27 channels with g.729 codec
> in meetme conferences. What is your point?
My point is people say "I'm having trouble with performance and adding lots of
users or handling lots of users... ooh! I'll use MySQL!" and end up only a
little better off, if at all.
> Well, since it works, and it works well in a number of environments. Or
> maybe because somebody somewhere decided to write the code for asterisk to
> make it work. If you have such a problem with postgres not being natively
> supported, then stop wasting time writing contrived emails, and write some
> code (or pay someone to do it).
I have no use for realtime or tying a DB directly to my PBX. That's
foolhardy.
> postgres DB solution.... You can't try to tell me that there are no
> cases where some other DB would perform better than postgres... well,
> you can, but then it's just a religion :)
I never said there was nothing faster or more featureful than Postgres.
However from a Free/Open Source standpoint, I do fully believe that
PostgreSQL is one of the best, if not the best RDBMS to be had. It's always
been faster than MySQL for complex queries, it's fully ACID-compliant, it's
got a shitload of APIs and it's got no license weirdness, unlike MySQL. For
anything small I recommend SQLite. MySQL has always been the speed king for
ultra-simple and onesie-twosie queries, but load it down or throw more than a
few concurrent queries at it and Postgres has *always* (even back in the
6.3/6.4 days) kicked its ass once you realized fsync was on by default. :-)
> Please read before you reply. I was pointing out that talking about
> historic versions of mysql is as helpful as talking about historic
> versions of postgres... ie, how does postgres 6.3 compare to mysql
> 5.0 ??
Well see above for the speed comparisons, I think it was PHPBuilder who did
such a comparison and came to the same conclusions as I just did, and this
was years ago when postgres was notoriously "slow". :-)
> Not quite..... mysql is the perfect solution for a small PBX, eg, a
> small office, where they might add that new user once every 6 months.
> That means that it MAY be possible for 2 calls per year to be delayed by
> 3 ms at one point in the call flow.... if there was actually any calls
> being processed at that precise time, and they weren't stuck at one
> point in the IVR while listening to some prompt etc...
Actually no, there's *ZERO* reason to have MySQL anywhere near a PBX for such
a small system, and generally speaking, (not a MySQL specific bash here)
having the DB a point of failure for your PBX is a very stupid thing, IMO.
Yes that's right, I said RealTime is a bad thing.
> Anyone implementing a large scale solution (or something that should be
> capable of scaling) should do their homework both in sizing their
> servers, and in determining the best hardware, OS, DB, PBX/soft
> switch/VoIP software, etc...
Exactly, and for hundreds of concurrent queries and dozens of hosts querying
and a few hosts updating you're gonna need far more hardware running MySQL
than you will running Postgres.
Do *I* have specific benchmarks? no, but I have lots of circumstantial and (a
word that escapes me at the moment) evidence that tells me I'm not full of
shit.
> Anyway, I'll just continue along my merry way for now, enjoying mysql.
I never said that it WOULDN'T work. I said there are better solutions for the
same money.
-A.
More information about the asterisk-dev
mailing list