[
https://issues.apache.org/jira/browse/PIG-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590656#action_12590656
]
Shravan Matthur Narayanamurthy commented on PIG-161:
----------------------------------------------------
@Pi,
Well there are a few other operators that belong to this backend specific
category like, POSort, PODistinct, POSplit. Also as far as the translation is
concerned we have separated the two layers for better work division. For every
backend, there needs to be a translator that converts the logical plan into
physical plan with the nuances of the backend factored in. Then there will
depending on the complexity of the backend there will be a separate translation
layer that converts the Physical plan into the backend specific implementation.
For ex., for hadoop, we will have this scheme - a separate logical to physical
& physical to Map Reduce. However, for local backend, just the logical to
physical translation should be able to build an executable plan. Not sure whats
the best way to divide these into a sensible package layout.
> Rework physical plan
> --------------------
>
> Key: PIG-161
> URL: https://issues.apache.org/jira/browse/PIG-161
> Project: Pig
> Issue Type: Sub-task
> Reporter: Alan Gates
> Assignee: Alan Gates
> Attachments: arithmeticOperators.patch, incr2.patch, incr3.patch,
> incr4.patch, incr5.patch, MRCompilerTests_PlansAndOutputs.txt,
> Phy_AbsClass.patch, pogenerate.patch, pogenerate.patch, pogenerate.patch,
> posort.patch
>
>
> This bug tracks work to rework all of the physical operators as described in
> http://wiki.apache.org/pig/PigTypesFunctionalSpec
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
