Mailing-List: contact dev-help@hawq.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hawq.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAFdmzJycpXunRk+je0e2N5PbmUBmhi7=Qi8nDzCygNtB7Db-gw@mail.gmail.com>
References: <CACkst5AR4WeHwRubZgWTqFb7R3+gENvntD_e3axj9YTRDsp_Kw@mail.gmail.com>
 <CAPgpW0Zz1CDkE5+EQcx+i+6QCj_70ZKVSknBBiTKYsBOQnzvVQ@mail.gmail.com> <CAFdmzJycpXunRk+je0e2N5PbmUBmhi7=Qi8nDzCygNtB7Db-gw@mail.gmail.com>
From: Kavinder Dhaliwal <kdhaliwal@pivotal.io>
Date: Wed, 31 Aug 2016 09:24:51 -0700
Message-ID: <CACkst5BoVrNsTTPYRemDWftEncz2gvyUhCEd=kxiHLo5OwDhFQ@mail.gmail.com>
Subject: Re: Planner invoked twice on master
To: dev@hawq.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11445d4c71716e053b60890c
archived-at: Wed, 31 Aug 2016 16:25:23 -0000

--001a11445d4c71716e053b60890c
Content-Type: text/plain; charset=UTF-8

Hi Lirong,

Thanks for the detailed and thorough response. It's really cleared things
up.

If you are looking for some guy "to be blamed" for making the decision
> of invoking the planner twice on master, unfortunately, that guy would be
> me, :).
>

Not at all. I wasn't sure if I had stumbled across a bug or a design
decision. It does seem based on your explanation that it was an odd
situation that didn't really lend itself to the most straightforward
solution


> IMO, for the long term, maybe the best solution is to embed the logic
> of resource negotiation into the planner. In that case, the output of the
> planner consists of the needed number of virtual segments and the
> associated optimal execution plan. The planner can be invoked just once on
> master.
>

This seems like a great next step for HAWQ, so hopefully we're able to
implement this in the near future.

Thanks again for the response

Kavinder

--001a11445d4c71716e053b60890c--