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) |
Date: | 2017-02-26 08:17:07 |
Message-ID: | CA+TgmoYe8Obw7qRbWhkxQQ3N4okjYEtuerp7H3jJwo88HOsevg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
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) |