Re: WIP: Upper planner pathification

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WIP: Upper planner pathification
Date: 2016-03-10 19:00:46
Message-ID: 20160310190046.wpfejx7dj4rj6bjb@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-03-10 13:48:31 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Igal @ Lucee.org 2016-03-10 19:07:20 Re: Proposal: RETURNING primary_key()
Previous Message Robert Haas 2016-03-10 18:58:01 Re: RFC: replace pg_stat_activity.waiting with something more descriptive