Re: WIP: Upper planner pathification - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: WIP: Upper planner pathification
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F8011CE78A@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: Upper planner pathification
List pgsql-hackers
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Mar 14, 2016 at 9:21 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> >> So, even though we don't need to define multiple hook declarations,
> >> I think the hook invocation is needed just after create_xxxx_paths()
> >> for each. It will need to inform extension the context of hook
> >> invocation, the argument list will take UpperRelationKind.
>
> > That actually seems like a pretty good point.  Otherwise you can't
> > push anything from the upper rels down unless you are prepared to
> > handle all of it.
>
> I'm not exactly convinced of the use-case for that.  What external
> thing is likely to handle window functions but not aggregation,
> for example?
>
WindowPath usually takes a SortPath. Even though extension don't want to
handle window function itself, it may want to add alternative sort logic
than built-in.
Unless it does not calculate expected cost, nobody knows whether WindowPath +
SortPath is really cheaper than WindowPath + CustomPath("GpuSort").

The supplied query may require to run group-by prior to window function,
but extension may not be interested in group-by on the other hands, thus,
extension needs to get control around the location where built-in logic
also adds paths to fetch the cheapest path of the underlying paths.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>




pgsql-hackers by date:

Previous
From: James Sewell
Date:
Subject: Re: Choosing parallel_degree
Next
From: Haribabu Kommi
Date:
Subject: Re: pg_hba_lookup function to get all matching pg_hba.conf entries