could it be composed maybe? a general version and then a sql version that exploits the additional info/abilities available there and uses the general version internally...
i assume the sql version can benefit from the logical phase optimization to pick join details. or is there more? On Tue, Jun 16, 2015 at 7:37 PM, Michael Armbrust <mich...@databricks.com> wrote: > this would be a great addition to spark, and ideally it belongs in spark >> core not sql. >> > > I agree with the fact that this would be a great addition, but we would > likely want a specialized SQL implementation for performance reasons. >