Re: WIP: Upper planner pathification

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: WIP: Upper planner pathification
Дата
Msg-id 20160310190046.wpfejx7dj4rj6bjb@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: WIP: Upper planner pathification  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Следующее
От: "Igal @ Lucee.org"
Дата:
Сообщение: Re: Proposal: RETURNING primary_key()