陈明雨 于2020年10月29日周四 下午12:24写道:
> > We can fiinish it when doing compaction, schema change.
> Currenlty we do have a approach to automatically convert v1 to v2, by
> setting config in be.conf.
> But this approach is totally uncontrollable, that we can't even know when
> it can finish.
>
> As fa
Replacing the query optimizer is a long-term work, I think it is not within the
scope of this discuss.
Our main concern here is how to ensure normal compilation when the address of
the maven repo is changed.
Here I still suggest to turn this variable address into an environment
variable, and u
> We can fiinish it when doing compaction, schema change.Currenlty we do have a
> approach to automatically convert v1 to v2, by setting config in be.conf.
But this approach is totally uncontrollable, that we can't even know when it
can finish. And it is both time consuming and space consumimg.
I don’t think it’s a problem as long as it is divided into several parts.
But now there is a problem that the v2 version of the table is actually
very few, it is difficult for us to truly verify the stability of v2 in a
certain version.
Or are there any points that can guide users to trigger the c
陈明雨 于2020年10月29日周四 上午9:56写道:
> I agree to disable the use of V1 storage format for newly created tables
> in version 0.14.
>
>
> But "automatically convert to V2" is a dangerous and time-consuming
> operation, we may need more discuss.
>
>
We can fiinish it when doing compaction, schema change.
+1
I think we can convert V1 to V2 in version 0.14 automatically.
And leave a configure to disable this convert.
However we should give user an easy way to make them know if there is V1
segment when we remove V1 code completely.
Thanks,
Zhao Chun
apache 于2020年10月29日周四 上午9:48写道:
> Hello every
I agree to disable the use of V1 storage format for newly created tables in
version 0.14.
But "automatically convert to V2" is a dangerous and time-consuming operation,
we may need more discuss.
--
此致!Best Regards
陈明雨 Mingyu Chen
Email:
chenmin...@apache.org
At 2020-10-29 09:48:25, "
Hello everyone:
At present, our V2 storage format has been developed for a long time, and V2
has many advantages that V1 does not have. The coexistence of V1 and V2 brings
a lot of code and cluster maintenance costs.
Therefore, I think the next version, that is, version 0.14 will disable the use
Hi Duo,
I found another dependency package with similar functions, let's see if I
can replace it.
Regarding the question of Calcite, we have previously investigated Calcite
for Doris to optimize the query framework.
After the evaluation, it is found that the access cost may be similar to
the reco