Our thinking in the "One SQL to rule them all" paper [1] is that there
are not "streams" and "tables". Both product and order_items are
time-varying relations (TVFs).
Whether it is a streaming query is determined by whether you specify
"EMIT STREAM" in the query, not by what objects are
> Does it matter which table is a steam? if the "STREAM" query runs
> continuously, the output (table) from the query is a stream, and likely
> this stream gives you delta updates periodically.
In my understanding, it does. If both tables are a stream, you get a change
stream from both. You're
>I'm interested in the STREAM case. My question is, if you use the STREAM
>keyword (either after SELECT or at the end), which of the tables is treated
>as a stream? Order_item, product or both?
Does it matter which table is a steam? if the "STREAM" query runs
continuously, the output (table) from
Without the STREAM keyword it's clear, it's the old-fashioned SQL, no issue
there.
I'm interested in the STREAM case. My question is, if you use the STREAM
keyword (either after SELECT or at the end), which of the tables is treated
as a stream? Order_item, product or both?
Viliam
On Fri, 20 Mar
I should have said that
SELECT * FROM order_item o JOIN product p USING(product_id)
(without the "STREAM" keyword) is a time-varying relation. You can
execute it at 10am, and it terminates, and again at 10.10am and get
different results. The difference is due to differences in both
product
TANG Wen-hui created CALCITE-3866:
-
Summary: ReturnTypes.AGG_SUM may cause "numeric field overflow"
on PostgreSQL when generate the sql after using the rule
AggregateJoinTransposeRule.EXTENDED.
Key: CALCITE-3866
On Thu, 19 Mar 2020 at 21:04, Julian Hyde wrote:
Suppose you execute that query at 10am and get a particular result. ... you
> execute again at 10.10am.
>
I execute that query at 10am and expect it to run continuously. My
understanding is that a query with `EMIT STREAM` will run continuously.
