You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@iotdb.apache.org by "Yuan Tian (Jira)" <ji...@apache.org> on 2022/12/11 07:43:00 UTC

[jira] [Assigned] (IOTDB-4005) Parallel the FragmentInstance execution

     [ https://issues.apache.org/jira/browse/IOTDB-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yuan Tian reassigned IOTDB-4005:
--------------------------------

    Assignee: Alima777  (was: Yuan Tian)

> Parallel the FragmentInstance execution
> ---------------------------------------
>
>                 Key: IOTDB-4005
>                 URL: https://issues.apache.org/jira/browse/IOTDB-4005
>             Project: Apache IoTDB
>          Issue Type: Improvement
>          Components: Core/Query
>            Reporter: Yuan Tian
>            Assignee: Alima777
>            Priority: Major
>
> Previously, we accelerate raw query data without value filter by split each sensor's scan execution into a thread pool, in this way, we can accelerate the decompress and decode phase in query processing.
> In current mpp, we only run one fragmentInstance in one thread, so all sensors in that FragmentInstance will only scan, decompress and decode one by one which cause the query performance won't reach the previous level.
> We need to rethink about how to parallel our FragmentInstance, and meanwhile we should also take memory control into account, the previous version may cause OOM problem while there exists too many sensors in one query.
> We should also take deadlock into account while doing memory controlling, in case of one sensor occupying all the remaining usable memory, another sensor can never get more memory, but the whole query must wait for each sensor returning at least one TsBlock.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)