Re: using CustomScan to inject nodes into the plan

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

In response to

Browse pgsql-hackers by date

  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