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 Mon, Apr 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us 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
* 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 break
On Tue, Apr 15, 2014 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. After a fast review of the custom-scan and cache-scan patches, it
seems to me that my original fears are
Hi,
On 2014-04-15 11:07:11 -0400, Robert Haas wrote:
On Tue, Apr 15, 2014 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On Tue, Apr 15, 2014 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 14, 2014 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. After a fast review of the custom-scan and cache-scan
patches, it seems to me that my original fears
On 24 March 2014 10:25, Kouhei Kaigai kai...@ak.jp.nec.com 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
Simon Riggs si...@2ndquadrant.com 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
On 24 March 2014 10:25, Kouhei Kaigai kai...@ak.jp.nec.com 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
Simon Riggs si...@2ndquadrant.com 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
浩平); Tom Lane
Cc: Kohei KaiGai; Stephen Frost; Shigeru Hanada; Jim Mlodgenski; Robert
Haas; PgHacker; Peter Eisentraut
Subject: Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)
Hello,
I adjusted the custom-plan interface patch little bit for the cache-only
scan patch
Kouhei Kaigai kai...@ak.jp.nec.com 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
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 {
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 about
Kouhei Kaigai kai...@ak.jp.nec.com 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
Kouhei Kaigai kai...@ak.jp.nec.com 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
On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost sfr...@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
* 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 Tue, Mar 4, 2014 at 7:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost sfr...@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
* 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. But
2014-03-04 23:09 GMT+09:00 Robert Haas robertmh...@gmail.com:
On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost sfr...@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
* 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
Stephen Frost sfr...@snowman.net 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
2014-03-04 23:10 GMT+09:00 Stephen Frost sfr...@snowman.net:
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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost sfr...@snowman.net 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
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
On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost sfr...@snowman.net 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
2014-03-05 5:52 GMT+09:00 Stephen Frost sfr...@snowman.net:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost sfr...@snowman.net wrote:
Alright- so do you feel that the simple ctidscan use-case is a
sufficient justification and example of how this can
On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost sfr...@snowman.net 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
On Mon, Mar 3, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost sfr...@snowman.net wrote:
Erm, my thought was to use a select() loop which sends out I/O requests
and then loops around waiting
* 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 exactly
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
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
On Mon, Mar 3, 2014 at 9:13 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Sat, Mar 1, 2014 at 9:04 PM, Stephen Frost sfr...@snowman.net
wrote:
Erm, my thought was to use a select() loop which sends out I/O requests
and then loops around
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
2014-03-01 22:38 GMT+09:00 Stephen Frost sfr...@snowman.net:
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
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-02 9:51 GMT+09:00 Stephen Frost sfr...@snowman.net:
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
* 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
On Wed, Feb 26, 2014 at 3:02 AM, Stephen Frost sfr...@snowman.net 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
On Wed, Feb 26, 2014 at 10:23 AM, Stephen Frost sfr...@snowman.net 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
On Fri, Feb 28, 2014 at 10:36 AM, Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Feb 26, 2014 at 3:02 AM, Stephen Frost sfr...@snowman.net 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
On Sat, Mar 1, 2014 at 8:49 PM, Stephen Frost sfr...@snowman.net 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
* 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
2014-03-02 10:29 GMT+09:00 Stephen Frost sfr...@snowman.net:
* 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
* 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
2014-03-02 10:38 GMT+09:00 Robert Haas robertmh...@gmail.com:
On Wed, Feb 26, 2014 at 10:23 AM, Stephen Frost sfr...@snowman.net 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
* 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 of the
2014-03-01 0:36 GMT+09:00 Stephen Frost sfr...@snowman.net:
* 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
* 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 my
2014-02-26 16:46 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
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
* 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 go
* 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
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 of a relation
2014-02-26 17:31 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
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,
* 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
* 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
* 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
* 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
On Sun, Feb 23, 2014 at 6:54 PM, Kohei KaiGai kai...@kaigai.gr.jp 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.
, 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: [HACKERS] Custom Plan node)
On Sun, Feb 23, 2014 at 6:54 PM, Kohei KaiGai kai
: Kaigai, Kouhei(海外, 浩平); Stephen Frost; Shigeru Hanada; Jim
Mlodgenski; Robert Haas; Tom Lane; PgHacker; Peter Eisentraut
Subject: Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)
On Sun, Feb 23, 2014 at 6:54 PM, Kohei KaiGai kai...@kaigai.gr.jp
wrote:
Folks
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: [HACKERS] Custom Plan node)
On Sun, Feb 23, 2014 at 6:54 PM, Kohei KaiGai kai...@kaigai.gr.jp
wrote
Hi Kaigai-san,
2014-02-25 13:28 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
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
Hi Kaigai-san,
2014-02-23 22:24 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
(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
* 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 the custom
* 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 to
* 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 the
* 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 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 to come
Hi Kaigai-san,
Sorry to leave the thread for a while.
2014-02-23 22:24 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
(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
2014-02-23 22:24 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
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
, February 25, 2014 12:41 AM
To: Kohei KaiGai
Cc: Kaigai, Kouhei(海外, 浩平); Stephen Frost; Jim Mlodgenski; Robert Haas;
Tom Lane; PgHacker; Peter Eisentraut
Subject: Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)
Hi Kaigai-san,
Sorry to leave the thread for a while.
2014-02-23 22:24
On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai kai...@ak.jp.nec.com 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
2014-01-29 Christian Convey christian.con...@gmail.com:
On Mon, Jan 27, 2014 at 7:14 PM, Kouhei Kaigai kai...@ak.jp.nec.com 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
...@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] Custom Plan node)
Hello,
The attached patches
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
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 changes
KaiGai-san,
2013/12/16 KaiGai Kohei kai...@ak.jp.nec.com:
(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;
Hi Kaigai-san,
2013/12/11 Kohei KaiGai kai...@kaigai.gr.jp:
2013/12/10 Shigeru Hanada shigeru.han...@gmail.com:
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.
Hi KaiGai-san,
2013/12/8 Kohei KaiGai kai...@kaigai.gr.jp:
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
Hanada-san,
Thanks for your reviewing,
2013/12/4 Shigeru Hanada shigeru.han...@gmail.com:
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
Thanks for fixing many my carelessness.
I didn't know seek was an irregular verb...
Best regards,
2013/12/4 Shigeru Hanada shigeru.han...@gmail.com:
2013/11/29 Kohei KaiGai kai...@kaigai.gr.jp:
I merged all the propositions from Jim. Thanks, it made the documentation
quality better. Also, I
Hi KaiGai-san,
2013/11/29 Kohei KaiGai kai...@kaigai.gr.jp:
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
2013/11/29 Kohei KaiGai kai...@kaigai.gr.jp:
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
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.
2013/11/19 Kohei KaiGai kai...@kaigai.gr.jp:
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
KaiGai
On Tue, Nov 19, 2013 at 9:41 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Thanks for your review.
2013/11/19 Jim Mlodgenski jimm...@gmail.com:
My initial review on this feature:
- The patches apply and build, but it produces a warning:
ctidscan.c: In function
On Mon, Nov 18, 2013 at 7:25 AM, Kohei KaiGai kai...@kaigai.gr.jp 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:
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 kai...@kaigai.gr.jp:
The attached patches provide a feature to implement custom scan node
that allows extension to replace a part
97 matches
Mail list logo
