>> Yeah. I'm still not exactly convinced that custom-scan will ever allow
>> independent development of new plan types (which, with all due respect to
>> Robert, is what it was being sold as last year in Ottawa). But I'm not
>> opposed in principle to committing it, if we can find a way to have a
> On Tue, Apr 15, 2014 at 10:44 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, Apr 14, 2014 at 4:43 PM, Tom Lane wrote:
> >>> Yeah. After a fast review of the custom-scan and cache-scan
> >>> patches, it seems to me that my original fears are largely
> >>> confirmed: the custom scan p
> Andres Freund writes:
> > What I think this discussion shows that this patch isn't ready for
> > 9.4. The first iteration of the patch came in 2013-11-06. Imo that's
> > pretty damn late for a relatively complex patch. And obviously we
> > don't have agreement on the course forward.
> > I don't
Andres Freund writes:
> What I think this discussion shows that this patch isn't ready for
> 9.4. The first iteration of the patch came in 2013-11-06. Imo that's
> pretty damn late for a relatively complex patch. And obviously we don't
> have agreement on the course forward.
> I don't think we nee
Hi,
On 2014-04-15 11:07:11 -0400, Robert Haas wrote:
> On Tue, Apr 15, 2014 at 10:44 AM, Tom Lane wrote:
> > Robert Haas writes:
> [ discussion ]
What I think this discussion shows that this patch isn't ready for
9.4. The first iteration of the patch came in 2013-11-06. Imo that's
pretty damn l
On Tue, Apr 15, 2014 at 10:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 14, 2014 at 4:43 PM, Tom Lane wrote:
>>> Yeah. After a fast review of the custom-scan and cache-scan patches, it
>>> seems to me that my original fears are largely confirmed: the custom scan
>>> patch is not
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> A concrete example here is setrefs.c, whose responsibilities tend to
> change from release to release. I think if we committed custom-scan
> as is, we'd have great difficulty changing setrefs.c's transformations
> ever again, at least if we hoped to not bre
Robert Haas writes:
> On Mon, Apr 14, 2014 at 4:43 PM, Tom Lane wrote:
>> Yeah. After a fast review of the custom-scan and cache-scan patches, it
>> seems to me that my original fears are largely confirmed: the custom scan
>> patch is not going to be sufficient to allow development of any truly
On Mon, Apr 14, 2014 at 4:43 PM, Tom Lane wrote:
> Simon Riggs writes:
>> [ assorted comments about custom-scan patch, but particularly ]
>
>> * The prune hook makes me feel very uneasy. It seems weirdly specific
>> implementation detail, made stranger by the otherwise lack of data
>> maintenance
> Simon Riggs writes:
> > [ assorted comments about custom-scan patch, but particularly ]
>
> > * The prune hook makes me feel very uneasy. It seems weirdly specific
> > implementation detail, made stranger by the otherwise lack of data
> > maintenance API calls. Calling that for every dirty page
> On 24 March 2014 10:25, Kouhei Kaigai wrote:
>
> > Brief summary of the current approach that has been revised from my
> > original submission through the discussion on pgsql-hackers:
> >
> > The plannode was renamed to CustomPlan, instead of CustomScan, because
> > it dropped all the hardcoded
Simon Riggs writes:
> [ assorted comments about custom-scan patch, but particularly ]
> * The prune hook makes me feel very uneasy. It seems weirdly specific
> implementation detail, made stranger by the otherwise lack of data
> maintenance API calls. Calling that for every dirty page sounds like
On 24 March 2014 10:25, Kouhei Kaigai wrote:
> Brief summary of the current approach that has been revised from my
> original submission through the discussion on pgsql-hackers:
>
> The plannode was renamed to CustomPlan, instead of CustomScan, because
> it dropped all the hardcoded portion that
gt; [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
> Sent: Monday, March 17, 2014 9:29 AM
> To: Kaigai Kouhei(海外 浩平); Tom Lane
> Cc: Kohei KaiGai; Stephen Frost; Shigeru Hanada; Jim Mlodgenski; Robert
> Haas; PgHacker; Peter Eisentraut
> Subject: Re: Custom Scan
> I was thinking more like
>
> typedef struct CustomPathFuncs {
> const char *name; /* used for debugging purposes only */
> NodeCopy_function node_copy;
> NodeTextOut_function node_textout;
> ... etc etc etc ...
> } CustomPathFuncs;
>
> typedef struct CustomPath {
>
Kouhei Kaigai writes:
> I expected to include simple function pointers for copying and text-output
> as follows:
> typedef struct {
> Planplan;
> :
> NodeCopy_functionnode_copy;
> NodeTextOut_function node_textout;
> } Custom;
I was thinking more like
typed
> Kouhei Kaigai writes:
> >> * Please drop the whole register_custom_provider/get_custom_provider
> API.
>
> > One thing I was worrying about is how copyObject() and nodeToString()
> > support set of function pointer tables around custom-scan node,
> > however, you suggested to change the assumpt
Kouhei Kaigai writes:
>> * Please drop the whole register_custom_provider/get_custom_provider API.
> One thing I was worrying about is how copyObject() and nodeToString() support
> set of function pointer tables around custom-scan node, however, you suggested
> to change the assumption here. So,
Tom, thanks for your detailed comments.
> I apologize for not having paid much attention to this thread so far.
> It kept getting stuck on my "to look at later" queue. Anyway, I've taken
> a preliminary look at the v7 patch now.
>
> While the patch seems roughly along the lines of what we talked
2014-03-05 5:52 GMT+09:00 Stephen Frost :
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost wrote:
>> > Alright- so do you feel that the simple ctidscan use-case is a
>> > sufficient justification and example of how this can be generally
>> > useful th
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost wrote:
> > Alright- so do you feel that the simple ctidscan use-case is a
> > sufficient justification and example of how this can be generally
> > useful that we should be adding these hooks to core..? I
On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost wrote:
> Alright- so do you feel that the simple ctidscan use-case is a
> sufficient justification and example of how this can be generally
> useful that we should be adding these hooks to core..? I'm willing to
> work through the patch and clean it u
I apologize for not having paid much attention to this thread so far.
It kept getting stuck on my "to look at later" queue. Anyway, I've
taken a preliminary look at the v7 patch now.
While the patch seems roughly along the lines of what we talked about
last PGCon, I share Stephen's unease about a
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost wrote:
> > 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 understan
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> >> During EXPLAIN, ExecInitNode() is called. If ExecInitNode() fires queries
> >> to foreign servers, those would be fired while EXPLAINing a query as well.
> >> We want t
2014-03-04 23:10 GMT+09:00 Stephen Frost :
>> The "cache_scan" module that I and Haribabu are discussing in another
>> thread also might be a good demonstration for custom-scan interface,
>> however, its code scale is a bit larger than ctidscan.
>
> That does sound interesting though I'm curious ab
Stephen Frost writes:
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> During EXPLAIN, ExecInitNode() is called. If ExecInitNode() fires queries
>> to foreign servers, those would be fired while EXPLAINing a query as well.
>> We want to avoid that. Instead, we can run EXPLAIN on that
* Robert Haas (robertmh...@gmail.com) wrote:
> 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 identi
2014-03-04 23:09 GMT+09:00 Robert Haas :
> On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost 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
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> During EXPLAIN, ExecInitNode() is called. If ExecInitNode() fires queries
> to foreign servers, those would be fired while EXPLAINing a query as well.
> We want to avoid that. Instead, we can run EXPLAIN on that query at foreign
> server.
On Tue, Mar 4, 2014 at 7:39 PM, Robert Haas wrote:
> On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost 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
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> Do you think it makes sense if my submission was only interface portion
> without working example?
No, we're pretty strongly against putting in interfaces which don't have
working examples in contrib- for one thing, we want to know when we
break it.
On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost 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
On Mon, Mar 3, 2014 at 9:13 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost
> wrote:
> > > Erm, my thought was to use a select() loop which sends out I/O requests
> > > and then loops around waiting to see who finishes it.
> > 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 lik
KaiGai,
* Stephen Frost (sfr...@snowman.net) wrote:
> And I'm still unconvinced of this approach and worry that it's going to
> break more often than it works. That's my 2c on it, but I won't get in
> the way if someone else wants to step up and support it.
Alright, having heard from Robert (tha
* Robert Haas (robertmh...@gmail.com) wrote:
> > http://www.postgresql.org/message-id/20131104032604.gb2...@tamriel.snowman.net
>
> Huh, somehow I can't remember reading that... but I didn't think I had
> missed any posts, either. Evidently I did.
You and everyone else- you'll note it got exactl
On Mon, Mar 3, 2014 at 10:43 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost wrote:
>> > Erm, my thought was to use a select() loop which sends out I/O requests
>> > and then loops around waiting to see who finishes it. It
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost wrote:
> > Erm, my thought was to use a select() loop which sends out I/O requests
> > and then loops around waiting to see who finishes it. It doesn't
> > parallelize the CPU cost of getting the rows bac
On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I don't see that parallelizing Append is any easier than any other
>> problem in this space. There's no parallel I/O facility, so you need
>> a background worker per append branch to wait on I/O
2014-03-02 10:38 GMT+09:00 Robert Haas :
> On Wed, Feb 26, 2014 at 10:23 AM, Stephen Frost wrote:
>> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
>>> IIUC, his approach was integration of join-pushdown within FDW APIs,
>>> however, it does not mean the idea of remote-join is rejected.
>>
>> For m
* Robert Haas (robertmh...@gmail.com) wrote:
> For what it's worth, and I can't claim to have all the answers here,
> this doesn't match my expectation. I think we'll do two kinds of
> parallelism. One will be parallelism within nodes, like parallel sort
> or parallel seqscan. Any node we parall
2014-03-02 10:29 GMT+09:00 Stephen Frost :
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> As you mentioned, it is a headache for packagers, and does not make
>> sense for us if packager disabled the feature that requires proprietary
>> drivers.
>
> No, I disagree with that. I don't expect this u
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't see that parallelizing Append is any easier than any other
> problem in this space. There's no parallel I/O facility, so you need
> a background worker per append branch to wait on I/O. And you have
> all the problems of making sure that the
On Sat, Mar 1, 2014 at 8:49 PM, Stephen Frost wrote:
>> This critique seems pretty odd to me. I haven't had the time to look
>> at this patch set, but I don't see why anyone would want to use the
>> background worker facility for GPU acceleration, which is what
>> KaiGai's trying to accomplish he
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Feb 26, 2014 at 3:02 AM, Stephen Frost wrote:
> > The line between a foreign table and a local one is becoming blurred
> > already, but still, if this is the goal then I really think the
> > background worker is where you should be focused, no
On Fri, Feb 28, 2014 at 10:36 AM, Stephen Frost wrote:
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
>> * Stephen Frost (sfr...@snowman.net) wrote:
>> > I don't see how you can be when there hasn't been any discussion that I've
>> > seen about how parallel query execution is going to change thin
On Wed, Feb 26, 2014 at 10:23 AM, Stephen Frost wrote:
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
>> IIUC, his approach was integration of join-pushdown within FDW APIs,
>> however, it does not mean the idea of remote-join is rejected.
>
> For my part, trying to consider doing remote joins *w
On Wed, Feb 26, 2014 at 3:02 AM, Stephen Frost wrote:
>> The custom-scan node is intended to perform on regular relations, not
>> only foreign tables. It means a special feature (like GPU acceleration)
>> can perform transparently for most of existing applications. Usually,
>> it defines regular t
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> As you mentioned, it is a headache for packagers, and does not make
> sense for us if packager disabled the feature that requires proprietary
> drivers.
No, I disagree with that. I don't expect this use-case to be very
common to begin with and telling
2014-03-02 9:51 GMT+09:00 Stephen Frost :
> KaiGai,
>
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> Now we have two options for GPU programming: CUDA or OpenCL.
>> Both of libraries and drivers are provided under the proprietary license,
>> so it does not fit for the core implementation of Postg
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> Now we have two options for GPU programming: CUDA or OpenCL.
> Both of libraries and drivers are provided under the proprietary license,
> so it does not fit for the core implementation of PostgreSQL, but
> extensions that shall be installed on
2014-03-01 22:38 GMT+09:00 Stephen Frost :
> KaiGai,
>
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> BTW, this kind of discussion looks like a talk with a ghost because
>> we cannot see the new interface according to the parallel execution
>> right now, so we cannot have tangible investigation w
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> BTW, this kind of discussion looks like a talk with a ghost because
> we cannot see the new interface according to the parallel execution
> right now, so we cannot have tangible investigation whether it becomes
> really serious backward incompa
2014-03-01 0:36 GMT+09:00 Stephen Frost :
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
>> * Stephen Frost (sfr...@snowman.net) wrote:
>> > I don't see how you can be when there hasn't been any discussion that I've
>> > seen about how parallel query execution is going to change things for us.
>>
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > I don't see how you can be when there hasn't been any discussion that I've
> > seen about how parallel query execution is going to change things for us.
> >
> If parallel query execution changes whole o
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > I (plan to) use custom-scan of course. Once a relation is referenced
> > and optimizer decided GPU acceleration is cheaper, associated custom-
> > scan node read the data from underlying relation (or in-memory cache
> > if exists) then move to the
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > IIUC, his approach was integration of join-pushdown within FDW APIs,
> > however, it does not mean the idea of remote-join is rejected.
>
> For my part, trying to consider doing remote joins *without* going through
> FDWs is just nonsensical. Wh
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> I (plan to) use custom-scan of course. Once a relation is referenced
> and optimizer decided GPU acceleration is cheaper, associated custom-
> scan node read the data from underlying relation (or in-memory cache
> if exists) then move to the shared me
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> IIUC, his approach was integration of join-pushdown within FDW APIs,
> however, it does not mean the idea of remote-join is rejected.
For my part, trying to consider doing remote joins *without* going
through FDWs is just nonsensical. What are you j
2014-02-26 17:31 GMT+09:00 Kouhei Kaigai :
> IIUC, his approach was integration of join-pushdown within FDW APIs,
> however, it does not mean the idea of remote-join is rejected.
> I believe it is still one of our killer feature if we can revise the
> implementation.
>
> Hanada-san, could you put t
> > > If you're looking to just use GPU acceleration for improving
> > > individual queries, I would think that Robert's work around backend
> > > workers would be a more appropriate way to go, with the ability to
> > > move a working set of data from shared buffers and on-disk
> > > representation
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > This regular one means usual tables. Even though custom implementation
> > may reference self-managed in-memory cache instead of raw heap, the
> > table pointed in user's query shall be a usual table.
> > In the past, Hanada-san had proposed an en
* Shigeru Hanada (shigeru.han...@gmail.com) wrote:
> Perhaps he meant to separate patches based on feature-based rule. IMO
> if exposing utilities is essential for Custom Scan API in practical
> meaning, IOW to implement and maintain an extension which implements
> Custom Scan API, they should be
2014-02-26 16:46 GMT+09:00 Kouhei Kaigai :
>> Just to come back to this- the other two "contrib module" patches, at least
>> as I read over their initial submission, were *also* patching portions of
>> backend code which it was apparently discovered that they needed. That's
>> a good bit of my com
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > Just to come back to this- the other two "contrib module" patches, at least
> > as I read over their initial submission, were *also* patching portions of
> > backend code which it was apparently discovered that they needed. That's
> > a good bit of
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > Yes, the part-1 patch provides a set of interface portion to interact
> > between the backend code and extension code. Rest of part-2 and part-3
> > portions are contrib modules that implements its feature on top of
> > custom-scan API.
>
> Just
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> This regular one means usual tables. Even though custom implementation
> may reference self-managed in-memory cache instead of raw heap, the table
> pointed in user's query shall be a usual table.
> In the past, Hanada-san had proposed an enhancement
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > > Instead of custom node, it might be better idea to improve FDW
> > > infrastructure to push join. For the starters, is it possible for
> > > the custom scan node hooks to create a ForeignScan node? In general,
> > > I think, it might be better f
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> Yes, the part-1 patch provides a set of interface portion to interact
> between the backend code and extension code. Rest of part-2 and part-3
> portions are contrib modules that implements its feature on top of
> custom-scan API.
Just to come back t
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > Instead of custom node, it might be better idea to improve FDW
> > infrastructure
> > to push join. For the starters, is it possible for the custom scan node
> > hooks to create a ForeignScan node? In general, I think, it might be better
> > for th
Hi Kaigai-san,
2014-02-23 22:24 GMT+09:00 Kohei KaiGai :
> (1) Interface to add alternative paths in addition to built-in join paths
I found that create_custom_path is not used at all in your patch.
I revised postgresql_fdw.c to use it like this.
...
/* Create join information which is store
Hi Kaigai-san,
2014-02-25 13:28 GMT+09:00 Kouhei Kaigai :
> The reason why I asked the question above is, I haven't been 100% certain
> about its usage. Indeed, semifactors is applied on a limited usage, but
> quite easy to reproduce by extension later (using clauselist_selectivity)
> if extension
em at appropriate places.
>
Let's focus on scan and join that we are currently working on.
Even if we need separate node type for grouping or sorting, it will not
be necessary to construct whole of the framework from the scratch.
For example, definition of CustomProvider table will be able to
, I do not see this change to be light weight. I was
expecting more of a list of hooks to be defined by the user and this
infrastructure just calling them at appropriate places.
> Thanks,
> --
> NEC OSS Promotion Center / PG-Strom Project
> KaiGai Kohei
>
>
> > -Original Message-
>
m: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
> Sent: Tuesday, February 25, 2014 5:59 PM
> To: Kohei KaiGai
> Cc: Kaigai, Kouhei(海外, 浩平); Stephen Frost; Shigeru Hanada; Jim
> Mlodgenski; Robert Haas; Tom Lane; PgHacker; Peter Eisentraut
> Subject: Re: Custom Scan APIs (Re
On Sun, Feb 23, 2014 at 6:54 PM, Kohei KaiGai wrote:
> Folks,
>
> Let me remind the custom-scan patches; that is a basis feature of
> remote join of postgres_fdw, cache-only scan, (upcoming) GPU
> acceleration feature or various alternative ways to scan/join relations.
> Unfortunately, small amou
_(nestloop|hashjoin|mergejoin)_path is probably useful
as example of extension implementation.
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei
> -Original Message-
> From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
> Sent: Tuesday, February 25, 2014 12:41 AM
>
2014-02-23 22:24 GMT+09:00 Kohei KaiGai :
> Folks,
>
> Let me remind the custom-scan patches; that is a basis feature of
> remote join of postgres_fdw, cache-only scan, (upcoming) GPU
> acceleration feature or various alternative ways to scan/join relations.
> Unfortunately, small amount of discuss
Hi Kaigai-san,
Sorry to leave the thread for a while.
2014-02-23 22:24 GMT+09:00 Kohei KaiGai :
> (1) Interface to add alternative paths in addition to built-in join paths
>
> This patch adds "add_join_path_hook" on add_paths_to_joinrel to allow
> extensions to provide alternative scan path in ad
2014-01-29 Christian Convey :
>
> On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai wrote:
>>
>> FDW's join pushing down is one of the valuable use-cases of this
>> interface,
>> but not all. As you might know, my motivation is to implement GPU
>> acceleration
>> feature on top of this interface, tha
On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai wrote:
> FDW's join pushing down is one of the valuable use-cases of this interface,
> but not all. As you might know, my motivation is to implement GPU
> acceleration
> feature on top of this interface, that offers alternative way to scan or
> join
Hi Stephen,
Thanks for your comments.
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > Is somebody available to volunteer to review the custom-scan patch?
>
> I looked through it a bit and my first take away from it was that the patches
> to actually use the new hooks were also making more ch
KaiGai Kohei,
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> Is somebody available to volunteer to review the custom-scan patch?
I looked through it a bit and my first take away from it was that the
patches to actually use the new hooks were also making more changes to
the backend code, leaving
.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kohei KaiGai
> Sent: Tuesday, January 14, 2014 11:20 PM
> To: Shigeru Hanada
> Cc: Kaigai, Kouhei(海外, 浩平); Jim Mlodgenski; Robert Haas; Tom Lane;
> PgHacker; Peter Eisentraut
> Subject: Re: Custom Scan APIs (Re: [HACKERS
KaiGai-san,
2013/12/16 KaiGai Kohei :
> (2013/12/16 14:15), Shigeru Hanada wrote:
>> (1) ctidscan
>> Is session_preload_libraries available to enable the feature, like
>> shared_*** and local_***? According to my trial it works fine like
>> two similar GUCs.
>>
> It shall be available; nothing di
Hi Kaigai-san,
2013/12/11 Kohei KaiGai :
> 2013/12/10 Shigeru Hanada :
>> The patches could be applied cleanly, but I saw a compiler warning
>> about get_rel_relkind() in foreign.c, but it's minor issue. Please
>> just add #include of utils/lsyscache.h there.
>>
> Fixed,
Check.
>> I have some m
Hi KaiGai-san,
2013/12/8 Kohei KaiGai :
> The attached patches include documentation fixup by Hanada-san,
> and relocation of is_managed_relation (the portion to check whether
> the relation is a foreign table managed by a particular FDW) and
> has_wholerow_reference.
> I didn't touch the EXPLAIN
Thanks for fixing many my carelessness.
I didn't know "seek" was an irregular verb...
Best regards,
2013/12/4 Shigeru Hanada :
> 2013/11/29 Kohei KaiGai :
>> I merged all the propositions from Jim. Thanks, it made the documentation
>> quality better. Also, I fixed up cosmetic stuff around whitesp
Hanada-san,
Thanks for your reviewing,
2013/12/4 Shigeru Hanada :
> I first reviewed postgres_fdw portion of the patches to learn the
> outline of Custom Plan. Wiki page is also a good textbook of the
> feature. I have some random comments about the basic design of Custom
> Plan:
>
> (1) IIUC a
2013/11/29 Kohei KaiGai :
> I merged all the propositions from Jim. Thanks, it made the documentation
> quality better. Also, I fixed up cosmetic stuff around whitespace <-> tab.
I found some typos in documents and comments. Please see attached
patch for detail.
--
Shigeru HANADA
fix_typo.pat
Hi KaiGai-san,
2013/11/29 Kohei KaiGai :
> The attached ones are the revised patches.
>
> I merged all the propositions from Jim. Thanks, it made the documentation
> quality better. Also, I fixed up cosmetic stuff around whitespace <-> tab.
>
> An actual code changes are to follow the changes in
2013/11/19 Kohei KaiGai :
> OK, I split them off. The part-1 is custom-scan API itself, the part-2 is
> ctidscan portion, and the part-3 is remote join on postgres_fdw.
These three patches can be applied with no conflict onto 2013-11-27
HEAD, but some fixes are necessary to build because commit
78
contrib/ctidscan/ctidscan.c:44: indent with spaces.
contrib/ctidscan/ctidscan.c:250: indent with spaces.
contrib/ctidscan/ctidscan.c:266: trailing whitespace.
contrib/postgres_fdw/deparse.c:1044: indent with spaces.
contrib/postgres_fdw/postgres_fdw.c:940: indent with spaces.
src/backend/commands/e
KaiGai
On Tue, Nov 19, 2013 at 9:41 AM, Kohei KaiGai wrote:
> Thanks for your review.
>
> 2013/11/19 Jim Mlodgenski :
> > My initial review on this feature:
> > - The patches apply and build, but it produces a warning:
> > ctidscan.c: In function ‘CTidInitCustomScanPlan’:
> > ctidscan.c:362:9:
On Mon, Nov 18, 2013 at 7:25 AM, Kohei KaiGai wrote:
> The attached patches are the revised custom-scan APIs.
>
My initial review on this feature:
- The patches apply and build, but it produces a warning:
ctidscan.c: In function ‘CTidInitCustomScanPlan’:
ctidscan.c:362:9: warning: unused variabl
Hi,
I tried to write up a wikipage to introduce how custom-scan works.
https://wiki.postgresql.org/wiki/CustomScanAPI
Any comments please.
2013/11/6 Kohei KaiGai :
> The attached patches provide a feature to implement custom scan node
> that allows extension to replace a part of plan tree with
2013/10/3 Robert Haas :
>>> I am a little less sanguine about the chances of a CustomJoin node
>>> working out well. I agree that we need something to handle join
>>> pushdown, but it seems to me that might be done by providing a Foreign
>>> Scan path into the joinrel rather than by adding a conce
On Thu, Oct 3, 2013 at 3:05 AM, Kohei KaiGai wrote:
> Sorry for my late response. I've tried to investigate the planner code
> to find out the way to integrate this custom api, and it is still in
> progress.
> One special handling I found was that create_join_plan() adjust
> root->curOuterRels pri
On Tue, Sep 10, 2013 at 11:45 PM, Kohei KaiGai wrote:
>> Fair enough, I think. So the action item for KaiGai is to think of
>> how the planner integration might work.
>>
> Do you think the idea I mentioned at the upthread is worth to investigate
> for more detailed consideration? Or, does it seem
1 - 100 of 115 matches
Mail list logo
