On Sat, Feb 25, 2017 at 10:00 AM, Kohei KaiGai wrote:
> I tried to add a description how custom-scan callbacks performs under the
> executor, and when invoked roughly.
> However, it is fundamentally not easy for most of people because it assumes
> FDW/CSP author understand
2017-02-25 1:40 GMT+09:00 Claudio Freire :
> On Fri, Feb 24, 2017 at 1:24 PM, Robert Haas wrote:
>> On Fri, Feb 24, 2017 at 7:29 PM, Kohei KaiGai wrote:
>>> This attached patch re-designed the previous v2 according to Robert's
On Fri, Feb 24, 2017 at 1:24 PM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 7:29 PM, Kohei KaiGai wrote:
>> This attached patch re-designed the previous v2 according to Robert's
>> comment.
>> All I had to do is putting entrypoint for
On Fri, Feb 24, 2017 at 7:29 PM, Kohei KaiGai wrote:
> This attached patch re-designed the previous v2 according to Robert's comment.
> All I had to do is putting entrypoint for ForeignScan/CustomScan at
> ExecShutdownNode,
> because it is already modified to call child node
t;> To: Kaigai Kouhei(海外 浩平) <kai...@ak.jp.nec.com>
>> Cc: Claudio Freire <klaussfre...@gmail.com>; Amit Kapila
>> <amit.kapil...@gmail.com>; pgsql-hackers <pgsql-hackers@postgresql.org>
>> Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps insid
...@gmail.com>; Amit Kapila
> <amit.kapil...@gmail.com>; pgsql-hackers <pgsql-hackers@postgresql.org>
> Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside
> ExecEndGather)
>
> On Fri, Feb 17, 2017 at 12:46 PM, Kouhei Kaigai <kai...@a
On Fri, Feb 17, 2017 at 12:46 PM, Kouhei Kaigai wrote:
> The attached patch is revised one.
>
> Invocation of Exec(Foreign|Custom)ParallelFinish was moved to
> ExecParallelRetrieveInstrumentation() not to walk on the plan-
> state tree twice.
> One (hypothetical) downside
<pgsql-hackers@postgresql.org>
> Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside
> ExecEndGather)
>
> On Mon, Feb 6, 2017 at 1:42 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote:
> > I also had thought an idea to have extra space to Instrumentati
On Mon, Feb 6, 2017 at 1:42 AM, Kouhei Kaigai wrote:
> I also had thought an idea to have extra space to Instrumentation structure,
> however, it needs to make Instrumentation flexible-length structure according
> to the custom format by CSP/FDW. Likely, it is not a good
...@gmail.com>; Robert Haas
> <robertmh...@gmail.com>; pgsql-hackers <pgsql-hackers@postgresql.org>
> Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside
> ExecEndGather)
>
> On Mon, Feb 6, 2017 at 1:00 AM, Claudio Freire <klaussfre...@gmail.com>
On Mon, Feb 6, 2017 at 1:00 AM, Claudio Freire wrote:
> On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote:
>>> If the use case for this is to gather instrumentation, I'd suggest calling
>>> the hook in RetrieveInstrumentation, and calling it
On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote:
>> If the use case for this is to gather instrumentation, I'd suggest calling
>> the hook in RetrieveInstrumentation, and calling it appropriately. It would
>> make the intended use far clearer than it is now.
>>
>> And if
...@gmail.com>; Robert Haas
> <robertmh...@gmail.com>; pgsql-hackers <pgsql-hackers@postgresql.org>
> Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside
> ExecEndGather)
>
> On Mon, Oct 31, 2016 at 11:33 AM, Kouhei Kaigai <kai...@ak.jp.nec.co
On Mon, Oct 31, 2016 at 11:33 AM, Kouhei Kaigai wrote:
> Hello,
>
> The attached patch implements the suggestion by Amit before.
>
> What I'm motivated is to collect extra run-time statistics specific
> to a particular ForeignScan/CustomScan, not only the standard
>
On Fri, Dec 2, 2016 at 9:20 PM, Haribabu Kommi wrote:
> Moved to next CF with "needs review" status.
There has not been much interest in this patch, moved again, this time
to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list
On Tue, Nov 1, 2016 at 1:33 AM, Kouhei Kaigai wrote:
> Hello,
>
> The attached patch implements the suggestion by Amit before.
>
> What I'm motivated is to collect extra run-time statistics specific
> to a particular ForeignScan/CustomScan, not only the standard
>
Hello,
The attached patch implements the suggestion by Amit before.
What I'm motivated is to collect extra run-time statistics specific
to a particular ForeignScan/CustomScan, not only the standard
Instrumentation; like DMA transfer rate or execution time of GPU
kernels in my case.
Per-node DSM
17 matches
Mail list logo