Re: Custom Scan APIs (Re: Custom Plan node)
Kohei KaiGai <kaigai@kaigai.gr.jp>
From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Kouhei Kaigai <kaigai@ak.jp.nec.com>,
Shigeru Hanada <shigeru.hanada@gmail.com>,
Jim Mlodgenski <jimmy76@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>, PgHacker <pgsql-hackers@postgresql.org>,
Peter Eisentraut <peter_e@gmx.net>
Date: 2014-03-04T14:24:20Z
Lists: pgsql-hackers
2014-03-04 23:09 GMT+09:00 Robert Haas <robertmhaas@gmail.com>: > On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost <sfrost@snowman.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. > That is definitely the point to be discussed here. Even though I *believe* I could put the callbacks needed to implement alternative join / scan, it may lead different conclusion from other person's viewpoint. At least, I could implement a custom-scan as an alternative of join using postgres_fdw, however, it's uncertain whether I could cover all the possible case we should care about. So, I'd like to see comments from others. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
- 784e762e886e 9.4.0 cited