From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: using CustomScan to inject nodes into the plan |
Date: | 2015-03-11 19:52:23 |
Message-ID: | CA+TgmoYJBSd+HsNR=+U-zqU=qvpa0M5ffY533nRcPXcYzbdDVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 11, 2015 at 3:48 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> The one problem with this 'combined' solution however is that CustomScan
> requires scanrelid - a valid index into the range table. When injecting
> the node directly above a Scan node, that seems to work just fine (just
> use the same value), but on other places (e.g. above a join) that's not
> possible :-(
>
> I see three options:
>
> (1) creating a fake range table entry in the planner_hook (but for
> which relation to choose?)
>
> (2) reusing an existing range table entry (but which one?)
>
> (3) allowing CustomScan either without a valid index into a range
> table (or maybe referencing join relations and such)
>
> The first two options seem quite ugly to me - fragile and error prone.
> What about the third one?
>
> I realize this is probably a misuse of the CustomScan API, but it's the
> best way to inject external nodes into the plan that I'm aware of.
>
> BTW: I know there's a custom-join patch in the current commitfest, but
> I'd like to stress out I'm not trying to replace the join itself - I'd
> like to inject a node below / above it.
I think you might want to have a look at the custom-join patch,
because I think it adopts approach #3 from the list above, and it
would be good to know whether that approach works for you.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-03-11 20:00:23 | Re: Precedence of standard comparison operators |
Previous Message | Peter Eisentraut | 2015-03-11 19:49:50 | Re: [patch] PL/Python is too lossy with floats |