Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather)

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
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

In response to

Browse pgsql-hackers by date

  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)