On Fri, Mar 4, 2016 at 2:37 PM, Andres Freund wrote:
> On 2016-02-12 15:56:45 +0100, Andres Freund wrote:
>> Hi,
>>
>>
>> On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
>> > I think the part about whacking around the FDW API is a little more
>> > potentially objectionable to others, so I want to
On 2016-02-12 15:56:45 +0100, Andres Freund wrote:
> Hi,
>
>
> On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
> > I think the part about whacking around the FDW API is a little more
> > potentially objectionable to others, so I want to hold off doing that
> > unless a few more people chime in w
2016-02-13 0:11 GMT+09:00 Robert Haas :
> On Fri, Feb 12, 2016 at 9:56 AM, Andres Freund wrote:
>> On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
>>> I think the part about whacking around the FDW API is a little more
>>> potentially objectionable to others, so I want to hold off doing that
>>>
On Fri, Feb 12, 2016 at 9:56 AM, Andres Freund wrote:
> On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
>> I think the part about whacking around the FDW API is a little more
>> potentially objectionable to others, so I want to hold off doing that
>> unless a few more people chime in with +1. Pe
Hi,
On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
> I think the part about whacking around the FDW API is a little more
> potentially objectionable to others, so I want to hold off doing that
> unless a few more people chime in with +1. Perhaps we could start a
> new thread to talk about that
ei(海外 浩平)
>> Cc: Andres Freund; Amit Kapila; pgsql-hackers
>> Subject: Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan
>> support
>> on readfuncs.c)
>>
>> On Wed, Feb 10, 2016 at 1:25 AM, Kouhei Kaigai wrote:
>> > It is pretty good!
>>
: Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan
> support
> on readfuncs.c)
>
> On Wed, Feb 10, 2016 at 1:25 AM, Kouhei Kaigai wrote:
> > It is pretty good!
> >
> > The attached patch (primary one) implements the above idea.
> >
> >
On Wed, Feb 10, 2016 at 1:25 AM, Kouhei Kaigai wrote:
> It is pretty good!
>
> The attached patch (primary one) implements the above idea.
>
> Now ExtensibleNode works as a basis structure of data container,
> regardless of CustomScan and ForeignScan.
> Also, fdw_private and custom_private are de-
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Monday, February 08, 2016 11:59 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Andres Freund; Amit Kapila; pgsql-hackers
> Subject: ##freemail## Re: CustomScan in a larger structure (RE: [HACKERS]
>
On Sun, Feb 7, 2016 at 7:28 PM, Kouhei Kaigai wrote:
> The new callbacks of T_ExtensibleNode will replace the necessity to
> form and deform process of private values, like as:
> https://github.com/pg-strom/devel/blob/master/src/gpujoin.c#L114
Yeah.
> It transforms a bunch of internal data of
> On Wed, Feb 3, 2016 at 11:57 PM, Kouhei Kaigai wrote:
> > At this moment, I tried to write up description at nodes/nodes.h.
> > The amount of description is about 100lines. It is on a borderline
> > whether we split off this chunk into another header file, in my sense.
> >
> >
> > On the other h
On Wed, Feb 3, 2016 at 11:57 PM, Kouhei Kaigai wrote:
> At this moment, I tried to write up description at nodes/nodes.h.
> The amount of description is about 100lines. It is on a borderline
> whether we split off this chunk into another header file, in my sense.
>
>
> On the other hands, I notice
: Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan
> support
> on readfuncs.c)
>
> On Wed, Feb 3, 2016 at 8:00 PM, Kouhei Kaigai wrote:
> >> Well, looking at this a bit more, it seems like the documentation
> >> you've written here is really mispl
On Wed, Feb 3, 2016 at 8:00 PM, Kouhei Kaigai wrote:
>> Well, looking at this a bit more, it seems like the documentation
>> you've written here is really misplaced. The patch is introducing a
>> new facility that applies to both CustomScan and ForeignScan, but the
>> documentation is only to do
> On Wed, Jan 27, 2016 at 9:36 PM, Robert Haas wrote:
> > On Mon, Jan 25, 2016 at 8:06 PM, Kouhei Kaigai wrote:
> >> Sorry for my late response. I've been unavailable to have enough
> >> time to touch code for the last 1.5 month.
> >>
> >> The attached patch is a revised one to handle private dat
On Wed, Jan 27, 2016 at 9:36 PM, Robert Haas wrote:
> On Mon, Jan 25, 2016 at 8:06 PM, Kouhei Kaigai wrote:
>> Sorry for my late response. I've been unavailable to have enough
>> time to touch code for the last 1.5 month.
>>
>> The attached patch is a revised one to handle private data of
>> fore
> On Thu, Jan 28, 2016 at 10:18 PM, Kouhei Kaigai wrote:
> > Do you think we shall allow to register same extensible node name for
> > different node types? Like, "GpuJoin" for any of CustomPath, CustomScan
> > and CustomScanState. Or, do we avoid this using different name for each?
>
> I'd say a
On Thu, Jan 28, 2016 at 10:18 PM, Kouhei Kaigai wrote:
> Do you think we shall allow to register same extensible node name for
> different node types? Like, "GpuJoin" for any of CustomPath, CustomScan
> and CustomScanState. Or, do we avoid this using different name for each?
I'd say a different n
> On Mon, Jan 25, 2016 at 8:06 PM, Kouhei Kaigai wrote:
> > Sorry for my late response. I've been unavailable to have enough
> > time to touch code for the last 1.5 month.
> >
> > The attached patch is a revised one to handle private data of
> > foregn/custom scan node more gracefully.
> >
> > The
On Mon, Jan 25, 2016 at 8:06 PM, Kouhei Kaigai wrote:
> Sorry for my late response. I've been unavailable to have enough
> time to touch code for the last 1.5 month.
>
> The attached patch is a revised one to handle private data of
> foregn/custom scan node more gracefully.
>
> The overall consens
age-
> From: Kaigai Kouhei(海外 浩平)
> Sent: Wednesday, December 02, 2015 5:52 PM
> To: 'Robert Haas'
> Cc: Andres Freund; Amit Kapila; pgsql-hackers
> Subject: Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan
> support
> on readfuncs.c)
>
&
> On Wed, Dec 2, 2015 at 4:06 AM, Andres Freund wrote:
> > On 2015-12-02 08:52:20 +, Kouhei Kaigai wrote:
> >> diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
> >> index 26264cb..c4bb76e 100644
> >> --- a/src/backend/nodes/copyfuncs.c
> >> +++ b/src/backend/nodes/cop
On Wed, Dec 2, 2015 at 4:06 AM, Andres Freund wrote:
> On 2015-12-02 08:52:20 +, Kouhei Kaigai wrote:
>> diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
>> index 26264cb..c4bb76e 100644
>> --- a/src/backend/nodes/copyfuncs.c
>> +++ b/src/backend/nodes/copyfuncs.c
>>
On 2015-12-02 08:52:20 +, Kouhei Kaigai wrote:
> diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
> index 26264cb..c4bb76e 100644
> --- a/src/backend/nodes/copyfuncs.c
> +++ b/src/backend/nodes/copyfuncs.c
> @@ -635,8 +635,12 @@ _copyWorkTableScan(const WorkTableScan *
> On Thu, Nov 26, 2015 at 5:27 AM, Kouhei Kaigai wrote:
> > I'm now implementing. The above design perfectly works on ForeignScan.
> > On the other hands, I'd like to have deeper consideration for CustomScan.
> >
> > My recent patch adds LibraryName and SymbolName on CustomScanMethods
> > to looku
On Thu, Nov 26, 2015 at 5:27 AM, Kouhei Kaigai wrote:
> I'm now implementing. The above design perfectly works on ForeignScan.
> On the other hands, I'd like to have deeper consideration for CustomScan.
>
> My recent patch adds LibraryName and SymbolName on CustomScanMethods
> to lookup the method
ustomScan in a larger structure (RE: [HACKERS] CustomScan
> support
> on readfuncs.c)
>
> > On Thu, Nov 19, 2015 at 10:11 PM, Kouhei Kaigai
> > wrote:
> > > The above two points are for the case if and when extension want to use
> > > variable length fields for
> On Thu, Nov 19, 2015 at 10:11 PM, Kouhei Kaigai wrote:
> > The above two points are for the case if and when extension want to use
> > variable length fields for its private fields.
> > So, nodeAlloc() callback is not a perfect answer for the use case because
> > length of the variable length fi
On Thu, Nov 19, 2015 at 10:11 PM, Kouhei Kaigai wrote:
> The above two points are for the case if and when extension want to use
> variable length fields for its private fields.
> So, nodeAlloc() callback is not a perfect answer for the use case because
> length of the variable length fields shall
> On Mon, Nov 16, 2015 at 9:03 PM, Kouhei Kaigai wrote:
> > I guess we will put a pointer to static ExtensibleNodeMethods structure
> > on ForeignScan, CustomScan, CustomScanState and etc...
>
> I think that makes it confusing. What I'd prefer to do is have only
> the name stored in the node, an
On Mon, Nov 16, 2015 at 9:03 PM, Kouhei Kaigai wrote:
> I guess we will put a pointer to static ExtensibleNodeMethods structure
> on ForeignScan, CustomScan, CustomScanState and etc...
I think that makes it confusing. What I'd prefer to do is have only
the name stored in the node, and then peopl
> On Wed, Nov 11, 2015 at 11:13 PM, Kouhei Kaigai wrote:
> > I agree with we have no reason why only custom-scan is allowed to have
> > serialize/deserialize capability. I can implement an equivalent stuff
> > for foreign-scan also, and it is helpful for extension authors, especially,
> > who trie
On Wed, Nov 11, 2015 at 11:13 PM, Kouhei Kaigai wrote:
> I agree with we have no reason why only custom-scan is allowed to have
> serialize/deserialize capability. I can implement an equivalent stuff
> for foreign-scan also, and it is helpful for extension authors, especially,
> who tries to imple
> > On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
> > > On 2015-11-11 14:59:33 -0500, Robert Haas wrote:
> > >> I don't see this as being a particularly good idea. The same issue
> > >> exists for FDWs, and we're just living with it in that case.
> > >
> > > It's absolutely horrible there
> On Thu, Nov 12, 2015 at 7:59 AM, Kouhei Kaigai wrote:
> >> On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote:
> >> > The attached main patch (custom-scan-on-readfuncs.v3.patch) once
> >> > removes TextOutCustomScan, thus all the serialized tokens become
> >> > known to the core backend, and a
On Thu, Nov 12, 2015 at 7:59 AM, Kouhei Kaigai wrote:
>> On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote:
>> > The attached main patch (custom-scan-on-readfuncs.v3.patch) once
>> > removes TextOutCustomScan, thus all the serialized tokens become
>> > known to the core backend, and add _readCu
> On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote:
> > The attached main patch (custom-scan-on-readfuncs.v3.patch) once
> > removes TextOutCustomScan, thus all the serialized tokens become
> > known to the core backend, and add _readCustomScan() at readfuncs.c.
> > It deserializes CustomScan n
On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai wrote:
> The attached main patch (custom-scan-on-readfuncs.v3.patch) once
> removes TextOutCustomScan, thus all the serialized tokens become
> known to the core backend, and add _readCustomScan() at readfuncs.c.
> It deserializes CustomScan nodes from
> Robert Haas writes:
> > On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
> >> Just better serialization doesn't actually help all that much. Being
> >> able to conveniently access data directly, i.e. as fields in a struct,
> >> makes code rather more readable. And in many cases more
> >> e
> On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
> > On 2015-11-11 14:59:33 -0500, Robert Haas wrote:
> >> I don't see this as being a particularly good idea. The same issue
> >> exists for FDWs, and we're just living with it in that case.
> >
> > It's absolutely horrible there. I don't se
Robert Haas writes:
> On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
>> Just better serialization doesn't actually help all that much. Being
>> able to conveniently access data directly, i.e. as fields in a struct,
>> makes code rather more readable. And in many cases more
>> efficient. Ha
On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
> On 2015-11-11 14:59:33 -0500, Robert Haas wrote:
>> I don't see this as being a particularly good idea. The same issue
>> exists for FDWs, and we're just living with it in that case.
>
> It's absolutely horrible there. I don't see why that's
On 2015-11-11 14:59:33 -0500, Robert Haas wrote:
> I don't see this as being a particularly good idea. The same issue
> exists for FDWs, and we're just living with it in that case.
It's absolutely horrible there. I don't see why that's a justification
for much. To deal with the lack of extensibl
On Mon, Nov 9, 2015 at 10:26 PM, Kouhei Kaigai wrote:
> It is a relevant topic of readfuncs support for custom-scan.
>
> Unlike CustomPath and CustomScanState, we don't allow custom-scan
> provider to define own and larger structure that embeds CustomScan
> at head of the structure, to support cop
m: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
> Sent: Tuesday, November 10, 2015 11:47 AM
> To: Robert Haas
> Cc: Amit Kapila; Andres Freund; pgsql-hackers
> Subject: Re: [HACKERS] CustomScan support on readfuncs.c
>
> On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai wrote:
> > Are you suggesting to pass the object name on software build time?
>
> Yes. That's what test_shm_mq and worker_spi already do:
>
> sprintf(worker.bgw_library_name, "test_shm_mq");
>
OK, I ripped out the portion around dfmgr.c.
On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai wrote:
> Are you suggesting to pass the object name on software build time?
Yes. That's what test_shm_mq and worker_spi already do:
sprintf(worker.bgw_library_name, "test_shm_mq");
> If so, it may load incorrect libraries when DBA renamed i
[HACKERS] CustomScan support on readfuncs.c
>
> On Fri, Nov 6, 2015 at 2:02 AM, Kouhei Kaigai wrote:
> > I tried to split the previous version into two portions.
> >
> > - custom-scan-on-readfuncs.v2.patch
> > It allows to serialize/deserialize Cust
On Fri, Nov 6, 2015 at 2:02 AM, Kouhei Kaigai wrote:
> I tried to split the previous version into two portions.
>
> - custom-scan-on-readfuncs.v2.patch
> It allows to serialize/deserialize CustomScan node as discussed upthread.
> Regarding of get_current_library_filename(), I keep this feature as
> -Original Message-
> From: Kaigai Kouhei(海外 浩平)
> Sent: Friday, November 06, 2015 11:23 AM
> To: 'Robert Haas'
> Cc: Amit Kapila; Andres Freund; pgsql-hackers
> Subject: RE: [HACKERS] CustomScan support on readfuncs.c
>
> > On Wed, Nov 4, 2
> On Wed, Nov 4, 2015 at 10:13 AM, Kouhei Kaigai wrote:
> > Sorry for my late.
> >
> > I confirmed that CustomScan support of readfuncs.c works fine using the
> > attached patch for the PG-Strom tree. It worked as expected - duplication,
> > serialization and deserialization by:
> > plan_dup = s
On Wed, Nov 4, 2015 at 10:13 AM, Kouhei Kaigai wrote:
> Sorry for my late.
>
> I confirmed that CustomScan support of readfuncs.c works fine using the
> attached patch for the PG-Strom tree. It worked as expected - duplication,
> serialization and deserialization by:
> plan_dup = stringToNode(no
> > On Tue, Sep 29, 2015 at 6:19 PM, Kouhei Kaigai wrote:
> > >> On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai
> > >> wrote:
> > >> >> Instead of doing this:
> > >> >>
> > >> >> +/* Dump library and symbol name instead of raw pointer */
> > >> >> appendStringInfoString(str, " :methods
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Saturday, October 03, 2015 5:44 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Amit Kapila; Andres Freund; pgsql-hackers
> Subject: ##freemail## Re: [HACKERS] CustomScan support on readfuncs.c
>
>
On Tue, Sep 29, 2015 at 6:19 PM, Kouhei Kaigai wrote:
>> On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai wrote:
>> >> Instead of doing this:
>> >>
>> >> +/* Dump library and symbol name instead of raw pointer */
>> >> appendStringInfoString(str, " :methods ");
>> >> -_outToken(str, no
> On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai wrote:
> >> Instead of doing this:
> >>
> >> +/* Dump library and symbol name instead of raw pointer */
> >> appendStringInfoString(str, " :methods ");
> >> -_outToken(str, node->methods->CustomName);
> >> +_outToken(str, node->meth
On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai wrote:
>> Instead of doing this:
>>
>> +/* Dump library and symbol name instead of raw pointer */
>> appendStringInfoString(str, " :methods ");
>> -_outToken(str, node->methods->CustomName);
>> +_outToken(str, node->methods->methods_l
[HACKERS] CustomScan support on readfuncs.c
>
> On Thu, Sep 24, 2015 at 9:19 PM, Kouhei Kaigai wrote:
> > Then, let's look back a bit. Next issue is how to reproduce
> > the "methods" pointer from the text representation.
> > I try to lookup the methods tab
On Thu, Sep 24, 2015 at 9:19 PM, Kouhei Kaigai wrote:
> Then, let's look back a bit. Next issue is how to reproduce
> the "methods" pointer from the text representation.
> I try to lookup the methods table using a pair of library
> and symbol name; probably, it is a straightforward way.
> The "met
> On Fri, Sep 25, 2015 at 6:49 AM, Kouhei Kaigai wrote:
>
>
> Hi,
>
> I tried to define two additional callbacks to support CustomScan
> on readfuncs.c.
>
> First of all, we need to pay attention how to treat output of
> TextOutCustomScan when additional text outp
On Fri, Sep 25, 2015 at 6:49 AM, Kouhei Kaigai wrote:
> Hi,
>
> I tried to define two additional callbacks to support CustomScan
> on readfuncs.c.
>
> First of all, we need to pay attention how to treat output of
> TextOutCustomScan when additional text output is generated.
> Only custom-scan pro
Hi,
I tried to define two additional callbacks to support CustomScan
on readfuncs.c.
First of all, we need to pay attention how to treat output of
TextOutCustomScan when additional text output is generated.
Only custom-scan provider knows what shall be displayed, so
all we can do is invoke a new
62 matches
Mail list logo
