Re: ITP: Slash, Sourceforge (fwd)
On Thu, Jan 27, 2000 at 03:52:23PM -0800, Erik wrote:
> > gross. why do people insist on using the non-free mysql when
> > postgres is (a) technically far superior and (b) free (BSD type
> > license)?
> >
> > i don't get it. postgres is much better, it's just as fast on
> > everything except *bulk* creation/updating of records (which is
> > of negligible importance for most web databases) - and even then,
> > mysql only achieves the extra speed because it lacks features like
> > record locking. for queries and normal use, mysql is no faster than
> > postgres.
>
> That is the whole point though. People use MySQL it is faster for
> what they are doing though.
i suspect that they're using it because a) it gets a lot more publicity
than postgres does (even in the so-called "open source" press), and b)
they heard a rumour that it's supposed to be faster.
> It doesn't matter which features of SQL92 are missing, as long as the
> features you want are still there.
that's semi-true up to a point...and that point is when you hit a
dead-end because the limitations/missing features prevent you from
doing what you want to do, or force you to do it in a clumsy and slow
workaround.
> When your running a site like slashdot, with as many hits as it
> receives you want to get the VERY most bang for your buck.
you didn't read what i wrote. the *ONLY* thing that mysql is faster at
is **BULK** insertion or updating of records. i.e. creation/updating
of hundreds of records in a single batch. it is no faster for single
queries or any other ordinary usage. The only time there is any
noticable speed difference is for databases that are batch updated,
which is *NOT* a model suited to or commonly implemented for interactive
usage on the web.
more significantly, mysql only achieves that speed in that one area by
not implementing other, more generally useful and important features -
like transactions, and record locking (!!), and only having a limited
SQL subset.
i.e. using mysql for a web db would not get you any more 'bang for
your buck' - in fact, it is likely to get you less because you have to
program your way around its limitations.
mysql is quite good for what it is - it's certainly far from being crap
software. however, it is extremely limited when compared to postgres AND
it is non-free. there is no compelling reason to use it for any database
backed web site. in fact, there's no compelling reason to use it for
any database...speed of non-interactive batch updates isn't terribly
important for most people.
if a person has already invested weeks of effort into mysql development,
then there's proably no great reason to change either...but if they're
still in the stage of selecting which backend db to use then postgres
is hard to beat - free, full-featured, fast, actively worked on, and
pleasant & helpful dev team.
for a dist like debian, where free software is the whole reason for
existence, then there really isn't any other choice than postgres.
> If you read the license it isn't incredibly restrictive either.
> The license may not fit the DFSG, but it is open source that i can
it's not open source, either - the Open Source Definition is almost
identical to the DFSG (the only changes are that all references to
Debian have been removed).
non-free is non-free. and free software that depends on non-free is not
an official part of debian, it belongs in contrib.
debian has an inherent preference for free software - we use it,
recommend it, and encourage others to use it. if the Slash code can
be made to use the free Postgres database (or other free sql db if
there are any) then any debian package of it *SHOULD* be modified to
do so...in fact, *MUST* be modified to do so if it is ever to go into
debian main rather than contrib.
btw, i've looked (very briefly) at the Slash 0.90 code. it's a lot
better than the 0.3 version. it also uses DBD::mysql, so shouldn't be
too hard to port to DBD::Pg - my estimate is a couple of days to a week
of part-time hacking.
i noticed that it uses a couple of auto-increment fields. these can be
implemented in postgres using a sequence and a trigger. e.g. to create
an auto-incrementing field called 'id' in table 'foo':
// --------------------------------------------------------
// include the autoinc function from postgresql contrib examples
CREATE FUNCTION autoinc()
RETURNS opaque
AS '/usr/lib/postgresql/modules/autoinc.so'
LANGUAGE 'c';
// --------------------------------------------------------
// now create a sequence for the autoinc id field.
CREATE SEQUENCE fooid;
// --------------------------------------------------------
// create the table
CREATE TABLE foo (
id int4 NOT NULL UNIQUE PRIMARY KEY,
stuff TEXT NOT NULL,
otherstuff TEXT NOT NULL
);
// --------------------------------------------------------
// finally, create the trigger that does the auto-inc
CREATE TRIGGER foo_nextid
BEFORE INSERT OR UPDATE ON foo
FOR EACH ROW
EXECUTE PROCEDURE autoinc (id, fooid);
craig
--
craig sanders
Reply to: