[
https://issues.apache.org/jira/browse/HAWQ-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15343639#comment-15343639
]
Hubert Zhang edited comment on HAWQ-850 at 6/22/16 3:20 AM:
------------------------------------------------------------
this is a subtask of HAWQ-800. To fix bug reproted in HAWQ-800, we need
refineCachedPlan interface. Details is described in issue description
was (Author: hubertzhang):
subtask
> Planner supports refineCachedPlan interface.
> --------------------------------------------
>
> Key: HAWQ-850
> URL: https://issues.apache.org/jira/browse/HAWQ-850
> Project: Apache HAWQ
> Issue Type: Improvement
> Components: Core
> Reporter: Hubert Zhang
> Assignee: Hubert Zhang
>
> in PBE(prepare bind execution) cases, plan will be cached, and only be
> generated once in postgres.
> But in HAWQ since resource is dynamic or elastic, the plan maybe changed
> during the different execution of PBE. Also, the file split allocation result
> which is stored in plan is dynamically too, so the split-vseg mapping may
> also be changed.
> For example, We call a plpgsql function which do "insert into t select * from
> t".
> in Prepare we cache the plan, with fixed split-vseg mapping(e.g. 10 blocks),
> but after insert, there would be 20 blocks so the old split-vseg mapping is
> invalid. We need to update it. Also when we call this function again and
> again, the data size of t may request more resource to handle it than the
> first call, so we should recalculate the entire plan with the new vseg number.
> This function is implemented in a interface called refineCachedPlan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
