<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal>> Do we really need a Postgres flame war on this list?<br>
<br>
<span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I don’t think it’s a flame war – we’ve
mostly been talking about how to properly use databases of any type. I was
really hoping this would be a constructive and informative conversation, which
this has mostly been if you can ignore the occasional generalizations. I’ve
definitely learned a lot this morning, both in ways that affirm my choices, and
in ways that make me want to take a second look at other choices.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Later,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Aran<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'> William Reardon
[mailto:william.reardon@gmail.com] <b>On Behalf Of </b>Bill Reardon<br>
<b>Sent:</b> Wednesday, August 19, 2009 12:36 PM<br>
<b>To:</b> Jonathan Brown<br>
<b>Cc:</b> 'David Fetter'; Aran Deltac; losangeles-pm@pm.org; 'Ask Bjørn
Hansen'<br>
<b>Subject:</b> Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for
MySQL<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Do we really need a Postgres flame war on this list?<br>
<br>
Jonathan Brown wrote: <o:p></o:p></p>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>If I need complex processing, I'll normally create aggregate tables, <o:p></o:p></pre><pre>which are then simple tables that are accessed with simple queries.<o:p></o:p></pre><pre>Now, this doesn't necessarily contradict the idea of doing data <o:p></o:p></pre><pre>processing as close to where the data lives as possible.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
</blockquote>
<pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Actually, it does.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>Doing no processing (at least none at query time - but rather offline, so to<o:p></o:p></pre><pre>speak, by creating aggregate tables) is still faster than doing the<o:p></o:p></pre><pre>processing at query time but doing it in the db. That is, it's often more<o:p></o:p></pre><pre>efficient to do the work once, offline. Whether that work is done in the db<o:p></o:p></pre><pre>or slightly above it, it's most likely still faster than doing the word in<o:p></o:p></pre><pre>the db but at query time.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>-----Original Message-----<o:p></o:p></pre><pre>From: <a
href="mailto:losangeles-pm-bounces+jbrown=reachlocal.com@pm.org">losangeles-pm-bounces+jbrown=reachlocal.com@pm.org</a><o:p></o:p></pre><pre>[<a
href="mailto:losangeles-pm-bounces+jbrown=reachlocal.com@pm.org">mailto:losangeles-pm-bounces+jbrown=reachlocal.com@pm.org</a>] On Behalf Of<o:p></o:p></pre><pre>David Fetter<o:p></o:p></pre><pre>Sent: Wednesday, August 19, 2009 11:49 AM<o:p></o:p></pre><pre>To: Aran Deltac<o:p></o:p></pre><pre>Cc: <a
href="mailto:losangeles-pm@pm.org">losangeles-pm@pm.org</a>; Ask Bjørn Hansen<o:p></o:p></pre><pre>Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for<o:p></o:p></pre><pre>MySQL<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>On Wed, Aug 19, 2009 at 11:22:21AM -0700, Aran Deltac wrote:<o:p></o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Here's how it goes, over and over and over again: when MySQL doesn't <o:p></o:p></pre><pre>have it, it's fluff and nobody could possibly want such frippery, <o:p></o:p></pre><pre>let alone need it. When they get some kind of nonstandard, buggy, <o:p></o:p></pre><pre>hemipygian implementation, it's suddenly the greatest thing and you <o:p></o:p></pre><pre>can't live without it.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>As to this, "storage layer" business, that's what we call the stuff <o:p></o:p></pre><pre>at the other end of the SCSI (alternate spelling: SAS) cable, or if <o:p></o:p></pre><pre>you're unlucky, the network cable.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Jim Gray<o:p></o:p></pre><pre><a
href="http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29"><http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29></a><o:p></o:p></pre><pre>measured this back in 2003, and those metrics have moved even <o:p></o:p></pre><pre>further toward his conclusion, which was essentially, "do all the <o:p></o:p></pre><pre>processing you can as close to where the data lives as you can arrange<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
</blockquote>
<pre>it."<o:p></o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><a
href="http://research.microsoft.com/apps/pubs/default.aspx?id=70001">http://research.microsoft.com/apps/pubs/default.aspx?id=70001</a><o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre>Good info, thanks.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>Clearly you didn't actually read it, or if you did, you didn't understand<o:p></o:p></pre><pre>it.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>But, I have to agree, the less you do *in* the database, and the more <o:p></o:p></pre><pre>you can shrug off processing to other parts of the system, the better.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>The more processing you do *as close as possible* to where they data is<o:p></o:p></pre><pre>actually stored, the better off you are. Read the paper.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>I like to treat my database as a very fast flat file storage engine <o:p></o:p></pre><pre>that does very little processing for me.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>Yes, that's a common mistake, but that it's common doesn't make it not be a<o:p></o:p></pre><pre>mistake. OO coders are especially prone to this mistake, but it's far from<o:p></o:p></pre><pre>unknown among other kinds of coders who don't understand what an RDBMS is or<o:p></o:p></pre><pre>what it does.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>If I need complex processing, I'll normally create aggregate tables, <o:p></o:p></pre><pre>which are then simple tables that are accessed with simple queries.<o:p></o:p></pre><pre>Now, this doesn't necessarily contradict the idea of doing data <o:p></o:p></pre><pre>processing as close to where the data lives as possible.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>Actually, it does.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>It just rules out the database itself - there are other ways to get <o:p></o:p></pre><pre>close to the DB. And, of course, there is no one-ring-to-rule them <o:p></o:p></pre><pre>all - sometimes you just have to do it in the database.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>You've got your assumptions backwards. There may be times when your RDBMS<o:p></o:p></pre><pre>simply can't do the work for you, say if you've got a broken piece of<o:p></o:p></pre><pre>garbage that's at least ten years out of date, and you *have* to take that<o:p></o:p></pre><pre>network hit, which is massively inefficient. Even then, you need to do<o:p></o:p></pre><pre>tremendously many operations on each byte you pull over the network to make<o:p></o:p></pre><pre>this worthwhile.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>This is what Facebook and others do (including my $employer), as much <o:p></o:p></pre><pre>as possible.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>Facebook is not making money. It's losing money, not least because it's<o:p></o:p></pre><pre>doing things that cost enormous amounts of money like not letting the RDBMS<o:p></o:p></pre><pre>do what it can.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Maybe there is truth in your statement that everyone hims-and-haws <o:p></o:p></pre><pre>about how useless features are, and then when MySQL supports it people <o:p></o:p></pre><pre>can't live without it. But, you should be aware that there is a <o:p></o:p></pre><pre>movement to not do a lot of complex processing within the database <o:p></o:p></pre><pre>itself.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>I'm aware that there are a bunch of people who've been (usually not<o:p></o:p></pre><pre>deliberately) misinformed. That doesn't make them well informed. It just<o:p></o:p></pre><pre>makes more work for me when it turns out that approach simply cannot be made<o:p></o:p></pre><pre>to work. I suppose if I were more mercenary, I'd encourage this kind of<o:p></o:p></pre><pre>thing, but I'd rather work on stuff other than fixing giant systems broken<o:p></o:p></pre><pre>by this kind of misapprehension.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Ignoring that and just assuming that people are being MySQL Zealots <o:p></o:p></pre><pre>isn't going to help anyone.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>My 2 cents of opinion.<o:p></o:p></pre><pre> <o:p></o:p></pre></blockquote>
<pre><o:p> </o:p></pre><pre>Everybody's entitled to an *informed* opinion. The thing is, Jim Gray went<o:p></o:p></pre><pre>out and measured in a technology-agnostic way, and he came to the opposite<o:p></o:p></pre><pre>conclusion.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Perhaps you'll go out and measure something different. It'll be worth your<o:p></o:p></pre><pre>very own Turing award if you manage to overturn the result in that paper.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Cheers,<o:p></o:p></pre><pre>David.<o:p></o:p></pre><pre>--<o:p></o:p></pre><pre>David Fetter <a
href="mailto:david@fetter.org"><david@fetter.org></a> <a
href="http://fetter.org/">http://fetter.org/</a><o:p></o:p></pre><pre>Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter<o:p></o:p></pre><pre>Skype: davidfetter XMPP: <a
href="mailto:david.fetter@gmail.com">david.fetter@gmail.com</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Remember to vote!<o:p></o:p></pre><pre>Consider donating to Postgres: <a
href="http://www.postgresql.org/about/donate">http://www.postgresql.org/about/donate</a><o:p></o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>Losangeles-pm mailing list<o:p></o:p></pre><pre><a
href="mailto:Losangeles-pm@pm.org">Losangeles-pm@pm.org</a><o:p></o:p></pre><pre><a
href="http://mail.pm.org/mailman/listinfo/losangeles-pm">http://mail.pm.org/mailman/listinfo/losangeles-pm</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>Losangeles-pm mailing list<o:p></o:p></pre><pre><a
href="mailto:Losangeles-pm@pm.org">Losangeles-pm@pm.org</a><o:p></o:p></pre><pre><a
href="http://mail.pm.org/mailman/listinfo/losangeles-pm">http://mail.pm.org/mailman/listinfo/losangeles-pm</a><o:p></o:p></pre><pre> <o:p></o:p></pre></div>
</div>
<pre>
This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use
of the intended recipient(s). Any disclosure, copying, distribution,
posting, or use of the information contained in or attached to this
email is prohibited unless permitted by the sender. If you have
received this email in error, please immediately notify the sender
via return email, telephone, or fax and destroy this original transmission
and its included files without reading or saving it in any manner.
Thank you.
</pre></body>
</html>