|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>|
|Cc:||Claudio Freire <klaussfreire(at)gmail(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather)|
|Views:||Raw Message | Whole Thread | Download mbox|
On Sat, Feb 25, 2017 at 10:00 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> 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 the overall behavior of optimizer / executor, not
> only APIs specifications.
I think the statements about Shutdown only being useful in parallel
mode aren't quite striking the right tone. In theory a node can hold
any kind of resources and find it worthwhile to release them at
shutdown time. I think we'll eventually find it useful to run
shutdown callbacks in other cases as well - e.g. when a Limit has been
filled. It's probably true that the undeniable need for this today is
in the parallel query case, but I'd like to have this text read in a
way that doesn't assert that this is the only possible use case,
because I don't think it is.
I rewrote the documentation along those lines a bit and committed this.
The Enterprise PostgreSQL Company
|Next Message||Robert Haas||2017-02-26 08:23:46||Re: Reduce lock levels for reloptions|
|Previous Message||Fabien COELHO||2017-02-26 07:47:22||Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)|