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.
>

Reply via email to