From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP: Upper planner pathification |
Date: | 2016-03-10 19:16:03 |
Message-ID: | 29766.1457637363@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-03-10 13:48:31 -0500, Tom Lane wrote:
>> 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.
I don't deny that you *could* continue to do things that way, but
I dispute that it's a good idea. Why can't you generate a Path tree
and then ask create_plan() to convert it? Otherwise you're buying
into knowing a whole lot about the internals of createplan.c, and having
to track changes therein.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-10 19:27:55 | Re: Freeze avoidance of very large table. |
Previous Message | Igal @ Lucee.org | 2016-03-10 19:07:20 | Re: Proposal: RETURNING primary_key() |