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

From Andres Freund
Subject Re: WIP: Upper planner pathification
Date
Msg-id 20160310190046.wpfejx7dj4rj6bjb@alap3.anarazel.de
Whole thread Raw
In response to Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2016-03-10 13:48:31 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I see that you made a lot of formerly externally visible make_* routines
> > static. The Citus extension (which will be open source in a few days)
> > uses several of these (make_agg, make_sort_from_sortclauses, make_limit
> > at least).
> 
> > Can we please re-consider making these static?
> 
> That was intentional: in my opinion, nothing outside createplan.c ought
> to be making Plan nodes anymore.  The expectation is that you make a
> Path describing what you want.  Can you explain why, in the new planner
> structure, it would be sane to have external callers of these functions?

In Citus' case a full PlannedStmt is generated on the master node, to
combine the data generated on worker nodes (where the bog standard
postgres planner is used).  It's not the only way to do things, but I
don't see why the approach would be entirely invalidated by the
pathification work.

We do provide the planner_hook, so restricting the toolbox for that to
do something useful, doesn't seem like a necessarily good idea.

- Andres



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: "Igal @ Lucee.org"
Date:
Subject: Re: Proposal: RETURNING primary_key()