Re: upper planner path-ification

On Thu, May 14, 2015 at 8:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Wed, May 13, 2015 at 10:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> For the reasons I mentioned, I'd like to get to a point where
> >> subquery_planner's output is Paths not Plans as soon as possible. But
> the
> >> idea of coarse representation of steps that we aren't trying to be smart
> >> about might be useful to save some labor in the short run.
> >>
> >> The zero-order version of that might be a single Path node type that
> >> represents "do whatever grouping_planner would do", which we'd start to
> >> break down into multiple node types once we had the other APIs fixed.
>
> > The problem I'm really interested in solving is gaining the ability to
> > add additional aggregation strategies, such as letting an FDW do it
> > remotely, or doing it in parallel. It seems to me that your proposed
> > zero-order version of that wouldn't really get us terribly far toward
> > that goal - it would be more oriented towards solving the other
> > problems you mention, specifically adding more intelligence to setops
> > and allowing parameterization of subqueries. Those things certainly
> > have some value, but I think supporting alternate aggregation
> > strategies is a lot more interesting.
>
> Clearly we'd like to get to both goals. I don't see the "zero order"
> design as something we'd ship or even have in the tree for more than
> a short time. But it might still be a useful refactorization step.
>
> In any case, the key question if we're to have Paths representing
> higher-level computations is "what do we hang our lists of such Paths
> off of?". If we have say both GROUP BY and LIMIT, it's important to
> distinguish Paths that purport to do only the grouping step from those
> that do both the grouping and the limit. For the scan/join part of
> planning, we do this by attaching the Paths to RelOptInfos that denote
> various levels of joining ... but how does that translate to the higher
> level processing steps? Perhaps we could make dummy RelOptInfos that
> correspond to having completed different steps of processing; but I've
> not got a clear idea about how many such RelOptInfos we'd need, and
> in particular not about whether we need to cater for completing those
> steps in different orders.
>
>
Given that the results of such computations are "relations", having a
RelOptInfo for each operation looks natural. Although, Sort/Order, which
doesn't alter the result-set but just re-orders it, may be an exception
here. It can be modeled as a property of some RelOptInfo rather than
modelling as a RelOptInfo by itself. Same might be the case of row locking
operation.

As Robert has mentioned earlier, reordering does open opportunities for
optimizations and hence can not be ignored. If we are restructuring the
planner, we should restructure to enable such reordering. One possible
solution would be to imitate make_one_rel(). make_one_rel() creates
possible relations (and paths for each of them) which represent joining
order for a given joinlist. Similarly, given a list of operations requested
by user, a function would generate relations (and paths for each of them)
which represent possible orders of those operations (operations also
include JOINs). But that might explode the number of relations (and hence
paths) we examine during planning.

> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company