Re: Custom Scan APIs (Re: Custom Plan node)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Custom Scan APIs (Re: Custom Plan node)
Date: 2014-03-04 14:09:26
Message-ID: CA+TgmobrsWQp_07gRH5fmwHp=_Rzih1SgE920FRoygq4q04EqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> As I mentioned
>> up-thread, I'd really like to see FDW join push-down, FDW aggregate
>> push-down, parallel query execution, and parallel remote-FDW execution
>> and I don't see this CustomScan approach as the right answer to any of
>> those.
>
> In accordance with the above, what I'd like to see with this patch is
> removal of the postgres_fdw changes and any changes which were for that
> support. In addition, I'd like to understand why 'ctidscan' makes any
> sense to have as an example of what to use this for- if that's valuable,
> why wouldn't we simply implement that in core? I do want an example in
> contrib of how to properly use this capability, but I don't think that's
> it.

I suggested that example to KaiGai at last year's PGCon. It may
indeed be something we want to have in core, but right now we don't.

More generally, I think this discussion is focusing on the wrong set
of issues. The threshold issue for this patch is whether there is a
set of hook points that enable a workable custom-scan functionality,
and whether KaiGai has correctly identified them. In other words, I
think we should be worrying about whether KaiGai's found all of the
places that need to be modified to support a custom scan, and whether
the modifications he's made to each of those places are correct and
adequate. Whether he's picked the best possible example does not
strike me as a matter of principal concern, and it's far too late to
tell him he's got to go pick a different one at this point anyway.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-03-04 14:10:41 Re: Custom Scan APIs (Re: Custom Plan node)
Previous Message Simon Riggs 2014-03-04 13:59:39 Re: ALTER TABLE lock strength reduction patch is unsafe