IMHO If you need those files for tests and you don't have a way to generate
them it is allowed to keep them.
You can add some readme file that explain their nature. You can also add a
check sum file.
Just my 2 cents
Enrico
Il Gio 16 Lug 2020, 05:40 Francis Chuang ha
scritto:
> I am +1 for
Haisheng Yuan created CALCITE-4126:
--
Summary: Stackoverflow error when applying JoinCommuteRule
Key: CALCITE-4126
URL: https://issues.apache.org/jira/browse/CALCITE-4126
Project: Calcite
Regarding CALCITE-4000, the PR should be ready to merge now. Thanks for all
the help from Feng, Danny and Chuwei!
-Rui
On Tue, Jul 14, 2020 at 11:11 PM Chunwei Lei wrote:
> Thank you for all your effort.
>
> Now there're only two issues(CALCITE-4000[1] and CALCITE-4118[2]) to
> be fixed in
If the number of operands is greater than a threshold, like 5, or 10, we can
just stop normalizing it.
But currently AND/OR in Calcite is always binary operator, IN is not supported
in RexNode world.
Anyway, the discussion is orthogonal with your pull request, and it doesn't
block the
Well, I think I now got your idea, I agree a specific operator sub-class plus a
special symmetric hash code is more efficient and extensible. But for the first
version, I would only consider binary operators because I could not figure out
how to implement an efficient equals for operator like
> I might be wrong, however, I did see "< vs >" normalization to reduce the
> search space. I added the normalization performance rather than aesthetics
> reasons.
Are you sure the performance gain is caused by "< vs >" normalization instead
of "=" normalization? Can you show me the test case?
The Apache Calcite team is pleased to announce the release of Apache
Calcite Avatica Go 5.0.0.
Avatica is a framework for building database drivers. Avatica
defines a wire API and serialization mechanism for clients to
communicate with a server as a proxy to a database. The reference
Avatica
Hi Rui,
Yes On the Beam side I am using Enum logical type. I thought I can use Int
sql type however i faced following issues.
Let assume my enum is [(0,Apple),(1,Orange),(2,Pears),(3,Banana)].
- If I map my Enum type to any calcite type. there can be other columns
which have the same sqltype. How
TL;DR: PMC members, would you vote for a release 1.24 if it includes
binary files necessary for testing?
I would like to include the InnoDB adapter [1] in release 1.24. It is
well written, well documented, and it is ready.
There is one problem: there are some binary files (in InnoDB format)
[2]
Hi Talat,
I am guessing when you say logical type, you mean something like this in
Beam [1].
My question is why do you need Calcite to support ENUM? If you use logical
type, you can define a ENUM by yourself and the underlying type can be a
Map. Map is supported by Calcite. So ENUM will be
Hi Julian,
Thanks for your answer. I dont know other dbs but Also Postgresql support
enum too[1]. Do you think supporting logical types makes more sense ? When
we define a new type that can be stored in a schema field. Is it possible ?
Thanks
[1]
In answer to your question, no, Calcite does not support ENUM. It
looks as if only MySQL does this.
One idiomatic SQL way to achieve this would be to define a CHECK
constraint that ensures that a column can only have a given set of
values. Then hopefully a storage system would compress repeated
>BTW, I don't understand why we need c? Isn't a*17+b good enough to avoid
the corner case?
That depends on the number of corner cases we want to avoid :)
a*17+b might be good enough.
Vladimir
Guava library's approach is pretty naive:
Hashing.combineUnordered
It just adds each byte together, I don't think it is better than the one you
proposed.
BTW, I don't understand why we need c? Isn't a*17+b good enough to avoid the
corner case?
On 2020/07/15 20:33:55, Haisheng Yuan wrote:
>
> a) compute xor of the hashes
> b) compute sum of the hashes
> c) compute product of the hashes (with 0 replaced by 1 to avoid 0*n=0)
> Then combine the three values somehow. For instance: (a*17+b)*17+c
That is really good one. Better than pure XOR.
I also found this in scala:
> things might be bad if we want do dedup RexNode children using
Set
I guess the following might work better than XOR:
a) compute xor of the hashes
b) compute sum of the hashes
c) compute product of the hashes (with 0 replaced by 1 to avoid 0*n=0)
Then combine the three values somehow. For
> 1) I do not like the idea of XOR-based hash code, because it would make
> ($1=$1) have the same hashcode as ($2=$2) and so on.
You have a point. However, is it really a concern? How frequent will it occur?
Especially when an operator like Join, Filter, that has the same input rel, but
with
I agree that extensibility might be helpful, however:
1) I do not like the idea of XOR-based hash code, because it would make
($1=$1) have the same hashcode as ($2=$2) and so on.
2) "$2 > $1 is reordered to $1 < $2, so that predicate a > b and b < a can
be reduced to a > b."
This reverting can
> Customized sql operator can also benefit. [1]
I am not sure if I missed something. Can you show me how can the customized sql
operator benefit from this?
e.g. geospatial operator intersect (it is input order insensitive):
boolean &&( geometry A , geometry B )
> Add a SqlOperator interface is
Haisheng Yuan created CALCITE-4124:
--
Summary: Stop invalidating metadata cache in VolcanoRuleCall
Key: CALCITE-4124
URL: https://issues.apache.org/jira/browse/CALCITE-4124
Project: Calcite
Ruben Q L created CALCITE-4123:
--
Summary: Make EnumerableMergeJoin constructor protected
Key: CALCITE-4123
URL: https://issues.apache.org/jira/browse/CALCITE-4123
Project: Calcite
Issue Type:
I have extended the logic to support all the symmetrical operators(=, <> ..)
and the binary comparison operators (>=, < ..),
not only just RexInputRef. Customized sql operator can also benefit. [1]
The way is to compare the operands with SqlKind first then fallback to their
hashcode (eargely
The Apache Jenkins build system has built Calcite-Master (build #1834)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1834/ to
view the results.
Thank you for all your effort.
Now there're only two issues(CALCITE-4000[1] and CALCITE-4118[2]) to
be fixed in 1.24.0.
As for CALCITE-4000, it needs a final review. Could you someone help review?
As for CALCITE-4118, I could not find the PR for it. Could someone some
point it out if I
missed
24 matches
Mail list logo
