Re: upper planner path-ification

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: upper planner path-ification
Date: 2015-05-17 02:31:08
Message-ID: CA+Tgmoa=DtMA_ons5tLZBMSftgEy6VFnX=hF+y5van3UemN_Hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

So, getting back to this part, what's the value of returning a list of
Paths rather than a list of Plans? It seems that, in general terms,
what we're trying to do is delay performing some of the work, so that
we can generate several candidates relatively inexpensively and decide
only later which one to turn into a Plan. What's not entirely clear
to me is which parts of the work we're trying to delay. For example,
target lists are normally computed when paths are converted to plans,
but for the higher-level plan nodes adding by grouping_planner, the
path list is typically just passed in. So would the new path types be
expected to carry target lists of their own, or would they need to
figure out the target list on the fly at plan generation time?

One thing that seems like it might complicate things here is that a
lot of planner functions take PlannerInfo *root as an argument. But
if we generate only paths in grouping_planner() and path-ify them
later, the subquery's root will not be available when we're trying to
do the Path -> Plan transformation. Presumably that means anything we
need from the PlannerInfo has to be dug out and saved in the path.

I think grouping_planner() is badly in need of some refactoring just
to make it shorter. It's over 1000 lines of code, which IMHO is a
fairly ridiculous length for a single function.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-05-17 02:56:07 jsonb concatenate operator's semantics seem questionable
Previous Message Robert Haas 2015-05-17 02:15:51 Re: WALWriteLock contention