From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: Custom Plan node |
Date: | 2013-09-10 10:54:52 |
Message-ID: | CAM-w4HOO3baJav=dJpN9y-FUw6xjdjxXoQMY2BZF5Ucvv9nUGg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 10, 2013 at 11:33 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I'd be willing to put in the infrastructure as soon as it's clear that we
>> have a way forward, but not if it's never going to be more than a kluge.
>
> Fair enough, I think. So the action item for KaiGai is to think of
> how the planner integration might work.
It's hard to imagine how the planner could possibly be pluggable in a
generally useful way. It sounds like putting an insurmountable barrier
in place that blocks a feature that would be useful in the Executor.
If you only want to handle nodes which directly replace one of the
existing nodes providing the same semantics then that might be
possible. But I think you also want to be able to interpose new nodes
in the tree, for example for the query cache idea.
Frankly I think the planner is hard enough to change when you have
full access to the source I can't imagine trying to manipulate it from
a distance like this.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-09-10 11:12:27 | Remove leftover prototype for inval_twophase_postcommit |
Previous Message | Greg Stark | 2013-09-10 10:48:15 | Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII |