That's correct. The 10m in the names weren't really meant to be
hardcoded into the patch, as the idea is that the tables could be
created at different sizes depending on your cluster size. Sorry for
the incomplete state of things, obviously that patch needs some work
before I commit it.
computations across
multiple stores.
Olga
-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com]
Sent: Saturday, December 20, 2008 10:33 AM
To: pig-dev@hadoop.apache.org
Cc: pig-dev@hadoop.apache.org
Subject: Re: Pig performance
I think the key points that Alan brought up
combine computations across
> multiple stores.
>
> Olga
>
> > -Original Message-
> > From: Ted Dunning [mailto:ted.dunn...@gmail.com]
> > Sent: Saturday, December 20, 2008 10:33 AM
> > To: pig-dev@hadoop.apache.org
> > Cc: pig-dev@hadoop.apache.
> Sent: Saturday, December 20, 2008 10:33 AM
> To: pig-dev@hadoop.apache.org
> Cc: pig-dev@hadoop.apache.org
> Subject: Re: Pig performance
>
>
> I think the key points that Alan brought up in his blog
> comment were that trunk pig is paradoxically not the most
> curr
I think the key points that Alan brought up in his blog comment were
that trunk pig is paradoxically not the most current and that storing
intermediate results can decrease the scope of optimizations.
On Dec 20, 2008, at 10:16, Alan Gates wrote:
I left a comment on the blog addressing som
I left a comment on the blog addressing some of the issues he brought
up.
Alan.
On Dec 20, 2008, at 1:00 AM, Jeff Hammerbacher wrote:
Hey Pig team,
Did anyone check out the recent claims about Pig's poor performance
versus
Cascading? Though I haven't worked extensively with either system,
