I don’t think there are any cases that absolutely HAVE to be in 1.14. If people
get a PR ready (working, and quality) in time, we’ll consider it. I listed the
10 (yes, ten!) PRs I am currently reviewing in 1970. I don’t think there will
be many more.
Julian
> On Aug 28, 2017, at 2:12 PM, Mich
Sounds good. Just a heads up that I'll only be online sporadically the rest
of the week as well. I started off the release branch with an initial
commit to change version numbers. Release tracking issue is linked below. I
marked all issues tagged for 1.13 as blockers. If anyone has issues they
don'
Michael Mior created CALCITE-1970:
-
Summary: Release Calcite 1.14.0
Key: CALCITE-1970
URL: https://issues.apache.org/jira/browse/CALCITE-1970
Project: Calcite
Issue Type: Bug
Repo
That would be great, Michael. Thank you.
You won’t need your signing key for a while. The first step is drafting release
notes, shepherding in the final PRs, and getting people to hold off risky
changes so that the main line stabilizes. That takes a few days.
I recommend creating a JIRA case (l
I'd be up for doing this although I'm out of the country until next week
and unfortunately I left my private key for signing at home.
--
Michael Mior
mm...@apache.org
2017-08-28 21:20 GMT+02:00 Julian Hyde :
> Any volunteers for a release manager?
>
> > On Aug 28, 2017, at 12:20 PM, Julian Hyde
I agree, BindableTableScan.computeSelfCost should take projects and filters
into account. Can you log a JIRA case for that.
Be aware that ProjectableFilterableTable is an “80:20” thing — easy, good
enough for simple cases, but maybe not expressive enough for hard cases.
TranslatableTable is pro
I gave some thought to performance and thread safety when I added materialized
view support. I didn’t follow through and test at high load and parallelism
because at that point, functionality was more important. I’m glad we’re having
the discussion now.
The solution I settled on is the actor mo
Any volunteers for a release manager?
> On Aug 28, 2017, at 12:20 PM, Julian Hyde wrote:
>
> Yes, the RM needs to be a committer. And in fact it is easier if they are a
> PMC member.
>
> But you can definitely help. You could manually run some tests: run the test
> suite against one of our su
Yes, the RM needs to be a committer. And in fact it is easier if they are a PMC
member.
But you can definitely help. You could manually run some tests: run the test
suite against one of our supported back-end databases, e.g. Elasticsearch or
MySQL or MongoDB, and log bugs. Build and run tests o
I agree that we should create a new release soon to continue
with our normal release cadence.
I would like CALCITE-1947 to go in before the release, I should
push it this week.
@Michael, AFAIK you need to be a committer to be the RM.
-Jesús
On 8/25/17, 6:27 PM, "LogSplitter" wrote:
>Hi,
>
Christian,
The implementation of the filter tree index is what I was referring to
indeed. In the initial implementation I focused on the rewriting coverage,
but now that the first part is finished, it is at the top of my list as
I think it is critical to make the whole query rewriting algorithm wo
At first I was using TranslatableTable for my adapters (read files in different
formats), but I realized that many rules apply only to
ProjectableFilterableTable, so I started using it to take advantage of all
these builtin rules.
Restricting the projects that need to be scanned is very importan
If the metadata was cached, that would be awesome, especially because
that would also improve the prformance regarding the metadata retrival
for the query currently being planned, although I am not sure how the
caching would work since the RelNodes are mutable.
Have you considered implementing
13 matches
Mail list logo
