Re: ITP: Slash, Sourceforge (fwd)
On Thu, Jan 27, 2000 at 06:09:39PM -0800, Chip Salzenberg wrote:
> According to Craig Sanders:
> > Why do people insist on using the non-free mysql when postgres is
> > (a) technically far superior and (b) free (BSD type license)?
>
> Well, I just got into the habit of using MySQL back when postgres was
> neither functionally complete nor known to be particularly reliable,
> while MySQL was.
i think that's why most people use mysql. historical reasons.
i also suspect that the "mysql is heaps faster than postgresql" line is
similar to the "freebsd networking code is faster than linux's" myth -
i.e. it was true in the distant past but those who repeat it a lot don't
bother to keep their "facts" up to date.
there are some things where mysql is faster than pg, and some things
where pg is faster than mysql. importance of these "things" is
application dependant :).
in my experience, postgres is plenty fast enough - e.g. on one of
my postgres servers at work, i have a postgres database containing
approximately 2.7 million rows of summarised radius records. this is
used for billing and for users to check how much of their online time
they have used. i can select all logins for a user (or a given IP
address for tracing security complaints) in a given month in around a
second. For example:
$ time newquery.pl USERNAME_CENSORED 1999 12 | wc -l
select id,username,login,duration,octets_in,octets_out from lineitems where
username = 'USERNAME_CENSORED' and login >= '1999-12-01' and login < '2000-01-01' order by login
179
real 0m0.896s
user 0m0.650s
sys 0m0.090s
and that's including the time it takes for perl to compile and run my
script, and format the output.
$ uptime
2:43pm up 11 days, 5:08, 9 users, load average: 14.58, 11.75, 9.50
as you can see, that is on a fairly heavily loaded machine.
/var/postgres is not even on a particularly fast drive - an IBM 32160
IDE drive, using ext2fs. if performance of this db mattered more to me,
then i'd run it on something faster...like a DAC960 using hardware raid
0+1 with LVD scsi drives and reiserfs. i.e. lots of room for performance
improvements before i need worry about postgres' speed. i could speed it
up even more by moving the historical data (everything older than, say
two months) into separate tables.
there are two factors which tip the scales in postgres' favour as far as
i am concerned. one reason is that Postgres is free software (in every
sense of the term). the other is features.
from the Pg FAQ (http://www.PostgreSQL.org/docs/faq-english.html):
"PostgreSQL has most features present in large commercial DBMS's,
like transactions, subselects, triggers, views, and sophisticated
locking. We have some features they don't have, like user-defined
types, inheritance, rules, and multi-version concurrency control
to reduce lock contention. We don't have foreign key referential
integrity or outer joins, but are working on them for our next
release."
also from the FAQ, in reference to performance:
"In comparison to MySQL or leaner database systems, we are slower
on inserts/updates because we have transaction overhead. Of course,
MySQL doesn't have any of the features mentioned in the Features
section above. We are built for flexibility and features, though we
continue to improve performance through profiling and source code
analysis."
another important factor is that postgres is a mature and stable product
- it's the result of around 1.5 decades of software evolution...from
early ingres to the current postgresql with a few complete rewrites and
redesigns along the way.
> Besides, Postgres95 didn't support SQL, IIRC.
pg95 did, i think. i believe it was the first version of pg that did.
acording to the postgres info page at http://www.postgresql.org/info.html :
"The original name of the software at Berkeley was Postgres. When
SQL functionality was added in 1995, its name was changed to
Postgres95. The name was changed at the end of 1996 to PostgreSQL."
> Please point me to a comparison of these programs' strong points.
www.postgresql.org is a good site for postgres info.
craig
--
craig sanders
Reply to: