<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Do we really need a Postgres flame war on this list?<br>
<br>
Jonathan Brown wrote:
<blockquote cite="mid:39D60072FBFB4E33A94E56F0EBFABCAE@reachloc1d087f"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">If I need complex processing, I'll normally create aggregate tables,
which are then simple tables that are accessed with simple queries.
Now, this doesn't necessarily contradict the idea of doing data
processing as close to where the data lives as possible.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">Actually, it does.
</pre>
</blockquote>
<pre wrap=""><!---->
Doing no processing (at least none at query time - but rather offline, so to
speak, by creating aggregate tables) is still faster than doing the
processing at query time but doing it in the db. That is, it's often more
efficient to do the work once, offline. Whether that work is done in the db
or slightly above it, it's most likely still faster than doing the word in
the db but at query time.
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:losangeles-pm-bounces+jbrown=reachlocal.com@pm.org">losangeles-pm-bounces+jbrown=reachlocal.com@pm.org</a>
[<a class="moz-txt-link-freetext" href="mailto:losangeles-pm-bounces+jbrown=reachlocal.com@pm.org">mailto:losangeles-pm-bounces+jbrown=reachlocal.com@pm.org</a>] On Behalf Of
David Fetter
Sent: Wednesday, August 19, 2009 11:49 AM
To: Aran Deltac
Cc: <a class="moz-txt-link-abbreviated" href="mailto:losangeles-pm@pm.org">losangeles-pm@pm.org</a>; Ask Bjørn Hansen
Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for
MySQL
On Wed, Aug 19, 2009 at 11:22:21AM -0700, Aran Deltac wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Here's how it goes, over and over and over again: when MySQL doesn't
have it, it's fluff and nobody could possibly want such frippery,
let alone need it. When they get some kind of nonstandard, buggy,
hemipygian implementation, it's suddenly the greatest thing and you
can't live without it.
As to this, "storage layer" business, that's what we call the stuff
at the other end of the SCSI (alternate spelling: SAS) cable, or if
you're unlucky, the network cable.
Jim Gray
<a class="moz-txt-link-rfc2396E" href="http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29"><http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29></a>
measured this back in 2003, and those metrics have moved even
further toward his conclusion, which was essentially, "do all the
processing you can as close to where the data lives as you can arrange
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->it."
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="http://research.microsoft.com/apps/pubs/default.aspx?id=70001">http://research.microsoft.com/apps/pubs/default.aspx?id=70001</a>
</pre>
</blockquote>
<pre wrap="">Good info, thanks.
</pre>
</blockquote>
<pre wrap=""><!---->
Clearly you didn't actually read it, or if you did, you didn't understand
it.
</pre>
<blockquote type="cite">
<pre wrap="">But, I have to agree, the less you do *in* the database, and the more
you can shrug off processing to other parts of the system, the better.
</pre>
</blockquote>
<pre wrap=""><!---->
The more processing you do *as close as possible* to where they data is
actually stored, the better off you are. Read the paper.
</pre>
<blockquote type="cite">
<pre wrap="">I like to treat my database as a very fast flat file storage engine
that does very little processing for me.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, that's a common mistake, but that it's common doesn't make it not be a
mistake. OO coders are especially prone to this mistake, but it's far from
unknown among other kinds of coders who don't understand what an RDBMS is or
what it does.
</pre>
<blockquote type="cite">
<pre wrap="">If I need complex processing, I'll normally create aggregate tables,
which are then simple tables that are accessed with simple queries.
Now, this doesn't necessarily contradict the idea of doing data
processing as close to where the data lives as possible.
</pre>
</blockquote>
<pre wrap=""><!---->
Actually, it does.
</pre>
<blockquote type="cite">
<pre wrap="">It just rules out the database itself - there are other ways to get
close to the DB. And, of course, there is no one-ring-to-rule them
all - sometimes you just have to do it in the database.
</pre>
</blockquote>
<pre wrap=""><!---->
You've got your assumptions backwards. There may be times when your RDBMS
simply can't do the work for you, say if you've got a broken piece of
garbage that's at least ten years out of date, and you *have* to take that
network hit, which is massively inefficient. Even then, you need to do
tremendously many operations on each byte you pull over the network to make
this worthwhile.
</pre>
<blockquote type="cite">
<pre wrap="">This is what Facebook and others do (including my $employer), as much
as possible.
</pre>
</blockquote>
<pre wrap=""><!---->
Facebook is not making money. It's losing money, not least because it's
doing things that cost enormous amounts of money like not letting the RDBMS
do what it can.
</pre>
<blockquote type="cite">
<pre wrap="">Maybe there is truth in your statement that everyone hims-and-haws
about how useless features are, and then when MySQL supports it people
can't live without it. But, you should be aware that there is a
movement to not do a lot of complex processing within the database
itself.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm aware that there are a bunch of people who've been (usually not
deliberately) misinformed. That doesn't make them well informed. It just
makes more work for me when it turns out that approach simply cannot be made
to work. I suppose if I were more mercenary, I'd encourage this kind of
thing, but I'd rather work on stuff other than fixing giant systems broken
by this kind of misapprehension.
</pre>
<blockquote type="cite">
<pre wrap="">Ignoring that and just assuming that people are being MySQL Zealots
isn't going to help anyone.
My 2 cents of opinion.
</pre>
</blockquote>
<pre wrap=""><!---->
Everybody's entitled to an *informed* opinion. The thing is, Jim Gray went
out and measured in a technology-agnostic way, and he came to the opposite
conclusion.
Perhaps you'll go out and measure something different. It'll be worth your
very own Turing award if you manage to overturn the result in that paper.
Cheers,
David.
--
David Fetter <a class="moz-txt-link-rfc2396E" href="mailto:david@fetter.org"><david@fetter.org></a> <a class="moz-txt-link-freetext" href="http://fetter.org/">http://fetter.org/</a>
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: <a class="moz-txt-link-abbreviated" href="mailto:david.fetter@gmail.com">david.fetter@gmail.com</a>
Remember to vote!
Consider donating to Postgres: <a class="moz-txt-link-freetext" href="http://www.postgresql.org/about/donate">http://www.postgresql.org/about/donate</a>
_______________________________________________
Losangeles-pm mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Losangeles-pm@pm.org">Losangeles-pm@pm.org</a>
<a class="moz-txt-link-freetext" href="http://mail.pm.org/mailman/listinfo/losangeles-pm">http://mail.pm.org/mailman/listinfo/losangeles-pm</a>
_______________________________________________
Losangeles-pm mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Losangeles-pm@pm.org">Losangeles-pm@pm.org</a>
<a class="moz-txt-link-freetext" href="http://mail.pm.org/mailman/listinfo/losangeles-pm">http://mail.pm.org/mailman/listinfo/losangeles-pm</a>
</pre>
</blockquote>
</body>
</html>