TableFunction is powerful: its input can be a table. So within the function
you can partition the table and apply computation over partitions. The only
question is what output do you expect. If you expect per partition result
(so TableFunction will return a table in this case), then you will
Can someone please review
https://github.com/apache/calcite-avatica/pull/138?
Once the PR is merged, I will start the voting process for Avatica 1.18.0.
Francis
On 25/02/2021 5:30 am, Alessandro Solimando wrote:
Hi all,
quick update, I have added some unit-tests to CALCITE-2489:
Yes there is definitely some similarity to groupby
What is this used for:
https://calcite.apache.org/javadocAggregate/org/apache/calcite/rel/logical/LogicalTableFunctionScan.html
Can i model a mapPartitions T -> U as ^ ?
On Thu, Mar 4, 2021 at 12:06 PM Rui Wang wrote:
> I feel like the
I feel like the mapPartitions can be implemented as a SELECT + GROUP BY,
where GROUP BY is to partition the data, then per partition computation is
handled by the SELECT.
-Rui
On Thu, Mar 4, 2021 at 11:56 AM Debajyoti Roy wrote:
> Thanks again Julian.
>
> Since, mapPartitions is really a
Thanks again Julian.
Since, mapPartitions is really a specialized map would it be best to model
it as a SELECT (similar to functions inside an expression) ?
Barring cases where h > h' and mapPartitions acts like a filter.
On Thu, Mar 4, 2021 at 11:41 AM Julian Hyde wrote:
> SQL has equivalents
SQL has equivalents of many functional programming idioms:
* map is SELECT
* filter is WHERE
* flatMap is similar to CROSS APPLY
That said, SQL’s strength is that the operations are not optimized for any
particular physical organization of data (e.g. working on sorted or partitioned
Thanks for the responses, adding some more color below.
Spark's API adopted concepts from the functional programming paradigm (map,
filter, flatmap,...) into data processing. Spark did add several relational
operators like join, union, select, etc. However, there are certain APIs
that are really
Benjamin Maquet created CALCITE-4523:
Summary: Using any SqlDialect returns java.lang.NoSuchFieldError:
EMPTY_CONTEXT
Key: CALCITE-4523
URL: https://issues.apache.org/jira/browse/CALCITE-4523
Thanks Roman. This information is very helpful!
On Thu, Mar 4, 2021 at 1:24 AM Roman Kondakov
wrote:
> Hello,
>
> Apache Ignite currently employs the top-down approach. Take a look at
> this package [1].
>
> The only documentation about the top-down I have seen so far can be
> found in this
hqx created CALCITE-4522:
Summary: optimize sort cost formula
Key: CALCITE-4522
URL: https://issues.apache.org/jira/browse/CALCITE-4522
Project: Calcite
Issue Type: Improvement
Components:
Hello,
Apache Ignite currently employs the top-down approach. Take a look at
this package [1].
The only documentation about the top-down I have seen so far can be
found in this javadoc [2]
You can also read several discussions on the devlist about this topic
[3], [4]
[1]
I searched for mapPartitions and flatMapGroupsWithState, and it looks as if you
are talking about Apache Spark operations. Can you give some examples of
typical queries that would use these operations?
It’s possible that these operations accomplish things that are not possible in
the
12 matches
Mail list logo
