Try pushing your key to the GNU, MIT and Ubuntu servers:
gpg --send-keys KEY_ID #GNU
gpg --keyserver pgp.mit.edu --send-keys KEY_ID #MIT
gpg --keyserver keyserver.ubuntu.com --send-keys KEY_ID #Ubuntu
After pushing your keys, check that they are sent to the server by
searching for your key
I have the same issue with Haisheng Yuan, what is the correct key server should
we use ?
Best,
Danny Chan
在 2019年5月3日 +0800 PM10:20,Stamatis Zampetakis ,写道:
> Apologies for the confusion.
>
> If there is still interest, I can participate again next week on
> http://tiny.cc/mku45y.
> We can also
I did not know this is how it works, I just copied the example above.
Would there be an easy way to create a RelNode containg a tablescan over
the materialized view "mv"?
Trying to create one using for instance a relbuilder gives a calcite
exception.
Otherwise I might just look for another test
bq . Since we are talking about materialized views, I think in most cases
tableRel should be simply a LogicalTableScan.
Stamatis is correct about this, I had not realized tableRel == queryRel in
your sample code.
Thanks,
Jesús
On Fri, May 3, 2019 at 6:12 AM Stamatis Zampetakis
wrote:
> I
Apologies for the confusion.
If there is still interest, I can participate again next week on
http://tiny.cc/mku45y.
We can also change the time to +/- 3 hours if that is more convenient for
other people.
@Haisheng: I have an issue with pgp.mit.edu keyserver (it seems to be down)
so I cannot
Hi Ivan,
It sounds like an interesting project, and I think Calcite will definitely
help you get there.
However your questions are quite broad so it is difficult to provide a
concrete answer.
The best place to get started is the official website [1] where there are a
lot of examples and
I think the main problem comes from the fact that tableRel == queryRel in
the test case you provided.
Defining the materialized view like that basically says that when you find
a part of the query that satisfies queryRel replace it with itself.
In conjunction with the rule that is used, which
Dear Jesus,
I think your intuition in this regard is correct.
After executing the main program in the HepPlanner the resulting plan
contains a lot of circular references.
Changing the matching order does not influence this behaviour.
Mark
On Thu, 2 May 2019 at 22:14, Jesus Camacho Rodriguez
Julian Hyde created CALCITE-3048:
Summary: Improve how JDBC adapter deduces current schema on
Redshift
Key: CALCITE-3048
URL: https://issues.apache.org/jira/browse/CALCITE-3048
Project: Calcite
Julian Hyde created CALCITE-3047:
Summary: In JDBC adapter, expose multiple schemas of the back-end
database
Key: CALCITE-3047
URL: https://issues.apache.org/jira/browse/CALCITE-3047
Project:
10 matches
Mail list logo